rates架构设计
其他
2019-04-03 16:05:44
阅读次数: 0
EhCache
cache资源分配
- CacheManager
- 公用一个cache manager,方便开发
- 整合spring cache的时候不需要使用多个cache manager的bean
- server resource
- 分为两个,一个用于存储业务live数据,一个用于存储系统数据
- resource pool
- 每个模块分配一个专用的resource pool
- cache
- 两害取其轻,采用clusteredShared
Redis策略
- 从数据量考虑不使用分布式存储,只用哨兵
- 使用AOF, appendfsync everysec保证数据丢失最多2s,同时兼顾性能
- no-appendfsync-on-rewrite no, 重写时候允许sync(),保证数据安全性
- repl-disable-tcp-nodelay no :如果后期发现吞吐量存在瓶颈,可以打开
- slowlog-log-slower-than 3000 :根据情况调整
- timeout 0: 连接池只在初始化之时创建,怕对连接池造成影响
- maxmemory :10G
- 内存溢出策略
- noeviction : 默认策略,不删除数据,只响应读操作,拒绝写操作并报错
- 也可以使用volatile-lru,但是需要分开管理live数据和用户永久性数据的超时时间,比较麻烦
- 连接方式
- live数据使用Jedis直连,发挥redis的单线程优势
- 用户请求同理,使用单线程避免高并发压力
- 其他非高并发操作使用reids-serivce
分布式计算设计
计算流程
- liberator datasource获取用户订阅的subject发布到kafka
- task订阅kafka的subject
- 调用DS进行分组服务
- 调用DS分组计算服务
- 调用DS所有分组服务,获取未订阅组
- 计算订阅比例
- 查询redis上次计算未订阅的时间,满两小时则计算
- 如果没有订阅,计算所以分组
- DS将用户订阅的所有subject
- DS提供将subject分组服务
- bond按国家分组,USD这种特别多的按个数分组USD_1/2/3/...
- DS提供获取所有分组服务
- DS提供分组计算服务
详解
- 解决多个liberator datasource重复发布subject的订阅和退订
- task认为每次订阅推定都有效,忽略个别不匹配情况
- 计算间隔
- 每30秒调用一次,如果正在计算则马上返回,sleep 1s重新寻找,直道找到
- 如何在计算的时候打开断路器,这样就不会得到正在计算的服务了?
- DS每次计算sleep 5s,释放cpu
- 周末重启默认重新订阅,所以无需存储订阅信息
- task不存在kafka消费者增加和减少重新分组问题
转载自www.cnblogs.com/judesheng/p/10649425.html