• Go第三方库 noGCMap 用于解决千万级MAP GC耗时过长问题(无hash冲突问题,对比fastcache bigcache等)... at
• Go实战 针对大型复杂map的GC优化, 变成map[uint64]int+外部二级索引切片 大幅减少GC耗时 at
• Go第三方库 golang业务级访客限流库(非网关级,如go.uber.org/ratelimit),已经前前后后使用好几年,比较稳定... at
• Go实战 纯 golang 实现精确实现滑动窗口限流,支持本地持久化,性能远超用 redis 实现的方案 (约 250 万/s) at
• Go基础 golang切片操作的各类辅助函数,包含,去重,删除,排序,倒序、随机、集合操作等 at

• Go实现网站访问量控制(滑动窗口算法,类似利用Redis List数据结构属性) at

暂无

暂无

最近的评论

• 评论了主题 针对大型复杂map的GC优化, 变成map[uint64]int+外部二级索引切片 大幅减少GC耗时
  #1楼 @Mericusta 会的,只要不是基础类型的map,在GC的时候都会被逐一扫描。高版本的GO对基础类型的MAP做了优化,不会被扫描
• 评论了主题 golang业务级访客限流库(非网关级,如go.uber.org/ratelimit),已经前前后后使用好几年,比较稳定...
  @wangchao 可以自己封装成HTTP服务,就支持多台机器了,不过性能会下降一个数量级。
• 评论了主题 golang业务级访客限流库(非网关级,如go.uber.org/ratelimit),已经前前后后使用好几年,比较稳定...
  @ddatsh 用途不一样呢,sentinel-go主要是网关,站点级别限流。上面这个是用户级别限流。
• 评论了主题 纯 golang 实现精确实现滑动窗口限流,支持本地持久化,性能远超用 redis 实现的方案 (约 250 万/s)
  #1楼 @liangmanlin 自行封装一个HTTP服务或者其它协议的服务即可解决多台服务机的问题。性能并不是问题的关键,虽然确实比redis快很多。主要是为了简单,并且服务稳定。
• 评论了主题 纯 golang 实现精确实现滑动窗口限流,支持本地持久化,性能远超用 redis 实现的方案 (约 250 万/s)
  这个可以自行封装一个HTTP服务,或者其它协议,比较简单,此处并没有实现。 相比redis方案,此方案主要在于: 1)简单,无依赖,至少你不用再装一个redis; 2)内存波动很小,不会有频繁的gc操作(但缺点也有,与此对应的是,初始化的时候,就预先分配了较大的内存); 3)性能并不是问题的关键,虽然确实比redis快很多。