EhCache

cache资源分配

• CacheManager
  1. 公用一个cache manager，方便开发
  2. 整合spring cache的时候不需要使用多个cache manager的bean
• server resource
  1. 分为两个，一个用于存储业务live数据，一个用于存储系统数据
• resource pool
  1. 每个模块分配一个专用的resource pool
• cache
  1. 两害取其轻，采用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
• 内存溢出策略
  1. noeviction ： 默认策略，不删除数据，只响应读操作，拒绝写操作并报错
  2. 也可以使用volatile-lru,但是需要分开管理live数据和用户永久性数据的超时时间，比较麻烦
• 连接方式
  1. live数据使用Jedis直连，发挥redis的单线程优势
  2. 用户请求同理，使用单线程避免高并发压力
  3. 其他非高并发操作使用reids-serivce

分布式计算设计

计算流程

• liberator datasource获取用户订阅的subject发布到kafka
• task订阅kafka的subject
  1. 调用DS进行分组服务
  2. 调用DS分组计算服务
  3. 调用DS所有分组服务，获取未订阅组
     1. 计算订阅比例
     2. 查询redis上次计算未订阅的时间，满两小时则计算
     3. 如果没有订阅，计算所以分组
• DS将用户订阅的所有subject
  1. DS提供将subject分组服务
     1. bond按国家分组,USD这种特别多的按个数分组USD_1/2/3/...
  2. DS提供获取所有分组服务
  3. DS提供分组计算服务

详解

• 解决多个liberator datasource重复发布subject的订阅和退订
  1. task认为每次订阅推定都有效，忽略个别不匹配情况
• 计算间隔
  1. 每30秒调用一次，如果正在计算则马上返回，sleep 1s重新寻找，直道找到
     1. 如何在计算的时候打开断路器，这样就不会得到正在计算的服务了？
  2. DS每次计算sleep 5s,释放cpu
• 周末重启默认重新订阅，所以无需存储订阅信息
• task不存在kafka消费者增加和减少重新分组问题