wechat
wechat copied to clipboard
silenceper
cache强耦合问题
在NewOfficialAccount和NewMiniProgram方法中，如果参数的cache为nil，则初始化失败。
cache只是用于设置AccessTokenHandle接口，对于大部分的应用来说，都会通过SetAccessTokenHandle方法来重新设置，但是初始化的时候必须提供一个非空的cache，否则不能通过。
建议：新增NewCustomOfficialAccount之类的函数，不对AccessTokenHandle进行配置；或者在DefaultAccessToken的GetAccessToken方法中进行判断cache是否为空。
不知道作者对此有什么看法？
感谢反馈，确实存在这个问题，这个可以优化一下： https://github.com/silenceper/wechat/blob/5c4b28acee44faeb2743610ad904c249ee95979f/officialaccount/officialaccount.go#L34
可以在这里判断cache 如果nil，则不进行赋值
在
NewOfficialAccount和NewMiniProgram方法中，如果参数的cache为nil，则初始化失败。 cache只是用于设置AccessTokenHandle接口，对于大部分的应用来说，都会通过SetAccessTokenHandle方法来重新设置，但是初始化的时候必须提供一个非空的cache，否则不能通过。建议：新增
NewCustomOfficialAccount之类的函数，不对AccessTokenHandle进行配置；或者在DefaultAccessToken的GetAccessToken方法中进行判断cache是否为空。不知道作者对此有什么看法？
same issue, use a fucking cache instead
you can take it below:
type FuckingCache struct {
}
func (c FuckingCache) Get(key string) (interface{}) {
fmt.Println("He wants to get a fucking cache hahaha!")
return nil
}
func (c FuckingCache) Set(key string, val interface{}, timeout time.Duration) error {
fmt.Println("He wants to set a fucking cache hahaha!")
return nil
}
func (c FuckingCache) IsExist(key string) bool {
fmt.Println("He wants to check the fucking cache is exist hahaha!")
return true
}
func (c FuckingCache) Delete(key string) error {
fmt.Println("He wants to delete fucking cache hahaha")
return nil
}
在
NewOfficialAccount和NewMiniProgram方法中，如果参数的cache为nil，则初始化失败。 cache只是用于设置AccessTokenHandle接口，对于大部分的应用来说，都会通过SetAccessTokenHandle方法来重新设置，但是初始化的时候必须提供一个非空的cache，否则不能通过。 建议：新增NewCustomOfficialAccount之类的函数，不对AccessTokenHandle进行配置；或者在DefaultAccessToken的GetAccessToken方法中进行判断cache是否为空。 不知道作者对此有什么看法？same issue, use a fucking cache instead
you can take it below:
type FuckingCache struct { } func (c FuckingCache) Get(key string) (interface{}) { fmt.Println("He wants to get a fucking cache hahaha!") return nil } func (c FuckingCache) Set(key string, val interface{}, timeout time.Duration) error { fmt.Println("He wants to set a fucking cache hahaha!") return nil } func (c FuckingCache) IsExist(key string) bool { fmt.Println("He wants to check the fucking cache is exist hahaha!") return true } func (c FuckingCache) Delete(key string) error { fmt.Println("He wants to delete fucking cache hahaha") return nil }
欢迎贡献PR @realpg @waro163
欢迎贡献PR @realpg @waro163
问题实在是太多了, 我还没决定是否采用, 正在评估阶段. 如果能采用, 可以贡献
第一个问题就是引用了这个库, 我镜像模拟了10%的测试流量, 服务器就炸了(我们业务上万QPS)
炸了的原因是log直接起飞,然后这个库连个调loglevel的地方都没有,一律debug
然后肉眼可见的内存暴涨,1小时内服务器就爆栈了, 感觉可能哪里还有泄漏
还有就像上面的FuckCache 这种接口的定义还不是附加在*struct上, 感觉里面还会有各种这种interface, 连成员变量都没法访问, 真的能用于生产环境么?
@realpg 你说的这些问题日志、性能 准备是放在新版https://github.com/silenceper/wechat/issues/583 中进行迭代优化
欢迎贡献PR @realpg @waro163
问题实在是太多了, 我还没决定是否采用, 正在评估阶段. 如果能采用, 可以贡献
第一个问题就是引用了这个库, 我镜像模拟了10%的测试流量, 服务器就炸了(我们业务上万QPS)
炸了的原因是log直接起飞,然后这个库连个调loglevel的地方都没有,一律debug
然后肉眼可见的内存暴涨,1小时内服务器就爆栈了, 感觉可能哪里还有泄漏
还有就像上面的FuckCache 这种接口的定义还不是附加在*struct上, 感觉里面还会有各种这种interface, 连成员变量都没法访问, 真的能用于生产环境么?
@realpg 你说的loglevel应该是这块的代码： https://github.com/silenceper/wechat/blob/108a65ecf34f2749170329e0a935f406d070b19d/wechat.go#L21-L31 这个是可以重新设置来disable输出的debug日志。
关于内存这块，我目前看到的有两处：
- 很多地方都是每次获取，重新创建对象，导致的该问题，因此我提了一个新的issue，就是将获取操作采用单例模式
- 除此之外，一些ServeHttp的地方没有采用连接池，高并发情况的确会发生内存问题，这也是需要优化的地方
建议作者创建一个交流群，这样可以讨论下特性实现及bug反馈问题等，也方便开发者们提pr，避免一些人想提交代码却在实现方面不大符合要求做无用功，同时可以避免开发者们对于同一个issue都提交代码，做一些重复工作。
在
NewOfficialAccount和NewMiniProgram方法中，如果参数的cache为nil，则初始化失败。cache只是用于设置
AccessTokenHandle接口，对于大部分的应用来说，都会通过SetAccessTokenHandle方法来重新设置，但是初始化的时候必须提供一个非空的cache，否则不能通过。建议：新增
NewCustomOfficialAccount之类的函数，不对AccessTokenHandle进行配置；或者在DefaultAccessToken的GetAccessToken方法中进行判断cache是否为空。不知道作者对此有什么看法？
可以支持传入nil 不设置就打个log就行