aaa

1.1      概要描述

加载流程可以分为4个阶段：

1.       加载准备：包含步骤1、2、3、4

2.       分批加载：包含步骤5

3.       重做redolog：包含步骤6、7、8、9、10、11[张西彦1] 

4.       启动服务：包含步骤12

 

详细描述中涉及的消息格式请参考附录。

2          详细描述

2.1      加载准备

1.       异常缓存关闭缓存集群的同步机制

如果异常缓存加载数据使用安静插入方法，可以不关闭缓存同步功能[张西彦2] 

2.       异常缓存向正常缓存发送数据加载请求

消息ID为1，消息内容为空。

3.       正常缓存准备数据加载

(1)    开始记录redologs

Redologs格式请参考附录

(2)    获取各个待同步的业务缓存的key列表并保存

(3)    打包待各个待同步缓存的记录个数成一个对象[张西彦3] 

待同步缓存个数对象格式请参考附录

4.       正常缓存准备数据加载完毕，向异常缓存发送响应消息

消息ID为1，消息内容为待同步缓存个数对象

 

2.2      分批加载

1.       异常缓存发送分批加载请求

消息ID为2，消息内容为空。

2.       正常缓存响应一批数据

正常缓存根据加载主备中记录的各个缓存的key列表，按照每条响应消息包可以包含的最大消息个数组装分批加载数据对象；

正常缓存需要记录已发送的数据，保证发送给异常缓存的数据没有重复。

分批加载数据对象格式请参考附录。

3.       异常缓存根据响应数据添加本缓存数据

异常缓存需要记录已从正常缓存接收的数据个数；

异常缓存向本地缓存添加数据需要使用线程池进行并行添加提高效率；

异常缓存根据记录的已接收数据个数和待同步缓存个数进行判断是否完成分批加载；

如果没有完成分批加载，则重复步骤1继续给正常缓存发送分批加载请求。

 

当前代码框架下，异常缓存发送分批加载请求使用了线程池，需要考虑多线程并发时，对共享数据（比如接收记录个数）的并发修改问题。[张西彦4] 

 

异常缓存需要考虑从正常缓存接收数据失败或者接收到无效数据的场景，接收失败或者接收到无效数据需要有重新获取机制；无效数据包括但不限于以下场景：

1.       正常缓存的响应消息中指示本消息包含了N条数据，但实际的数据个数不为N

[张西彦5] 

2.3      重做Redologs[张西彦6] 

1.       异常缓存判断分批加载完毕，向正常缓存请求redologs

2.       正常缓存结束记录redologs

向异常缓存发送redologs

3.       异常缓存重做redologs，重做完成后向正常缓存发送重做完成信息

4.       正常缓存收到异常缓存重做完成信息后，删除本地的redologs，并给异常缓存回确认收到信息

 

异常缓存需要考虑从正常缓存接收redologs失败或者接收到redologs无效的场景，接收失败或者接收的redologs无效需要有重新获取机制；无效的redologs包括但不限于以下场景：

1.       redologs中某个缓存的redolog指示本redolog包含了N条数据，但实际的数据个数不为N

[张西彦7] 

2.4      启动服务

1.       打开缓存数据同步功能[张西彦8] 

2.       创建缓存服务端监听[张西彦9] 

---

 [张西彦1]有没有必要一直重做，是否会很耗性能？是否考虑db做log

 [张西彦2]关闭集群同步机制不考虑，原因是没有找到相关的资料去实现，采用安静put用程序倒是可以实现。

 [张西彦3]打包各个待同步缓存的记录个数成一个对象

 [张西彦4]必须考虑。

 [张西彦5]无效场景，是需要考虑重新获取的。

不限于这一个无效场景。

 [张西彦6]初期只做一次，先观察一下效能。

 [张西彦7]同上。

 [张西彦8]不需要考虑，在web容器正常启动后，缓存的底层同步机制会默认挂起。

 [张西彦9]也不需要考虑，在web容器启动中，即使缓存服务端监听任务挂起，但是只要web容器没启动完毕，该任务也是没办法提供服务的。

所以：web容器启动成功后，缓存服务端监听任务和缓存数据同步监听都会默认挂起。