改进策略

单体 -> 横向扩展 -> 纵向扩展-> 一致性hash

单体

每个服务端后台通过spring task 跑自己的定时任务

横向扩展： 复制一个新节点

后来一个app撑不住，所以通过k8s起了2个pod， 通过横向扩展提高app的并发量，却引入了新的问题，2个节点同时触发定时任务，每个app每天被调用2次定时任务。

这个时候又有 2个方案

1. 定时任务添加分布式锁
   优点：快速解决问题
   缺点：引入分布式锁，并且每个app都跑相同的定时任务，增加额外的性能开销

2. 纵向扩展，将定时任务单独抽离
   缺点：花费更多的时间开发，增加了一点网络开销
   优点： 性能，扩展性，可用性兼具

纵向切割：将一个方法切成2块

单体的纵向切割只是一个开始，要充分发挥它的优势需要用一致性hash支持其可扩展。

一致性hash：数据分片

鉴于目前应用都部署在k8s上，所以为了这次主要通过添加一致性hash改进项目，使其支持弹性伸缩。

单节点：所有数据在一个数据轮上

单节点hash

新增节点：只从下一个节点获取数据

image.png

删除节点：将数据返回下一个节点

单节点hash

结论

无论新增或者删除节点，受影响的只有下一个节点，这样可以防止数据发生大规模变化。使用虚拟节点可以使数据分配更加均匀随机。

核心流程

节点新增

节点新增

节点删除

节点删除

节点api

节点api

技术点

基于redis的消息队列
redis共享内存：节点数据，节点所属数据
mysql持久化数据,日志信息记录
quartz 定时任务+延时任务
一致性hash
murmur3 hash算法

具体代码

目前代码和业务存在一定耦合，之后在试用，优化，解耦后贴出。