一、微服务多节点批量应该怎么设计？
1、异步任务分类：
- 周期性定时任务调度任务
- 批量任务
2、需要考虑并解决的问题：
2.1、避免同一任务同时被多个节点捞取。
1）数据库的行级锁
2）redis分布式锁
3）quartz集群
2.2、需要考虑各节点的本地系统时间差问题。
场景：某个节点如果很快执行完定时调度任务，另外一个节点的本地时间才到预计执行时间那么就会造成同一个调度任务被重复执行的情况。
解决办法：
1)如果使用的数据库，如果采用关系型数据库进行控制，那么任务数据行除了添加执行状态，再增加预计执行完时间字段，每次调度时需要判定系统时间是否大于上一次预计执行完时间，只有大于才会执行，小于说明该任务的本次调度已经被其他节点执行过了，那么所有节点都去争抢下一次执行。
2）如果使用的redis，则需要带上过期时间并支持续约。
2.3、批量任务需要多节点协同完成
场景：调用服务发生超时需要进行超时结果确认，将超时确认任务插入任务表等待批量任务调度挨个去执行查证。
解决方案：
1）每个节点捞取当前待执行任务状态的任务，如果为0则return，如果不为0则将任务状态变更为执行中，如果更新的条数和查询的条数相等，则执行，否则自调用。如果调度频率较高，可能导致部分节点一直处于自旋状态浪费性能。
2）增加slot槽点字段（假设在0-1000进行随机），每个节点在查询执行任务之前先计算开始槽点和结束槽点（先通过服务发现查询当前存在的所有批量节点（假设5个）并排序，找到自己的序号（假设为3），开始槽点=1000/5*（3-1），结束槽点就等于开始槽点+1000/5），然后带上槽点条件进行查询。
3）使用消息队列，每个节点从消息队列获取任务执行。
二、分表后的分页查询问题怎么解决？
1、场景1：历史表和当前业务表分页查询
如果根据日期排序且查询日期区间有数据落到历史表，则可以先查历史表，然后判断查询结果是否等于pageSize,如果等于0，则查询历史表的total，然后根据total计算应该查询当前表的行数。
2、场景2：按拆分字段水平拆分多个表后的分页查询
方案1） 全局视野法：
将所有分表从0开始到当前查询页的数据都查出来到内存中进行重新排序并取出当前页的数据。
缺点：随着页数增加，会导致内存占用过大。
方案2）禁止跳页查询：
不允许跳页查询，只能查下一页，查询时记住每个分表的最大值，然后下一页查询时只需去取每个分表从最大值下一个值开始的一页数据回来到内存中重新排序计算并记录新的最大值。
缺点：不支持跳页查询
方案3）二次查询法：
1）limit offset(all) pageSize 改写成：limit offset(all)/nodeSize pageSize
用改写后的sql去每个分表查询；
2）上一步查询的所有分表结果合并后取最小值minInall，合并前每个分表查询结果的最大值为max(i)，再改写sql为：between minInall and max(i);
3）找出minInall在各个分表中的下标为offset(i)，则可以计算出minInall在全局视野中的offset，offset（minInall）=offset(1)+offset(2)+offset(3)+...+offset(nodeSize)。
4）将第2）步中查到的所有结果进行排序，根据offset(all)和offset（minInall）的大小关系可以从排序结果中精确取出需要页的精确数据。
缺点：只适合于分表数据分布均衡的情况。因为第二次查询取出的数据量大小与每个分表的数据分布情况有关，如果数据分布非常均衡，则可以做到第二次查询每个分表只取出一页的数据量，如果数据分布不均衡则最坏情况下会退化成全局视野法的情况（比如极端情况：每个分表的数据都是按日期升序，这种情况可以根据分表的日期区间升序规律简化算法为场景1的情况）
详细可参考下面博客：
https://www.51cto.com/article/596385.html
)
)
)
)
)