在 Rancher 中实现集群的部署与测试 ( 负载均衡 与 命令行下的 Redis 锁定、性能提升 )

1、在 Rancher 中，克隆已经存在的 Docker 容器 channel-pub-api-prev 为 channel-pub-api-prev-1、channel-pub-api-prev-2，如图1

图1

2、最终 3 个容器组成了一个集群，如图2

图2

3、在负载均衡中，添加服务规则，设置域名与目标容器的映射关系，如图3

图3

4、在 Postman 中执行了 2 次请求，第 1 次为 GET，第 2 次为 POST，最终在容器 channel-pub-api-prev 中有一条 GET 请求日志，在容器 channel-pub-api-prev-1 中有一条 POST 请求日志，在容器 channel-pub-api-prev-2 中无请求日志，负载均衡设置符合预期，如图4

图4

5、在 3 个容器中，均在基于 Supervisor 监听队列，在队列所调用的服务中，输出日志至文件中，最终在容器 channel-pub-api-prev 中有一条服务日志，表明队列作业在容器 channel-pub-api-prev 中执行的。如图5

图5

6、查看 命令行下的 Redis 锁定日志，不仅存在 判断Redis模型的锁定是否存在(已存在)，而且存在 Redis模型的锁定实现时失败的 日志。时间：14:58 – 14:50 = 9 分钟。锁定次数：29 + 31 + 10 = 70 。锁定频率：70 / 9 = 8，即每分钟 8 次。如图6

图6

7、锁定频率过高的根源应该在于命令行中仅有同一条任务在执行。决定模拟出 6 条任务，锁定频率应该会有所下降。时间：15:52 – 15:47 = 6 分钟。锁定次数：47 + 34 + 45 = 126 。锁定频率：126 / 6 = 9，即每分钟 20 次。不符合预期。

8、决定调整 bash sleep 3 为 bash sleep 60，即命令行运行一次后，间隔 60 秒后再次运行，而不是 3 秒。重复第 7 步骤，不存在 Redis 锁定日志。符合预期。

9、基于同步时间、ID顺序排列(企鹅号的事务)。某一任务开始执行时，更新企鹅号的事务的同步时间为当前时间 ，以提升执行性能，且再次降低锁定频率。

10、模拟出 3 条任务。事务ID为 41、42、43 的同步时间(分钟)分别为：9、9、8 。事务ID为 41、42、43 的同步次数分别为：22、20、17 。事务ID为 41、42、43 的同步频率分别为：9 * 60 / 22 = 25、9 * 60 / 20 = 27、8 * 60 / 17 = 28。得出平均值：(25 + 27 + 28) / 3 = 27。理论上的计算公式，进一法取整(事务数量 / 5) / 容器数量 * 60。符合预期。如图7

图7

11、模拟出 5 条任务。事务ID为 47、48、49、52、53 的同步时间(分钟)分别为：4、11、4、5、5 。事务ID为 47、48、49、52、53 的同步次数分别为：10、20、10、9、10 。事务ID为 47、48、49、52、53 的同步频率分别为：4 * 60 / 10 = 24、11 * 60 / 20 = 33、4 * 60 / 10 = 24、5 * 60 / 9 = 33、5 * 60 / 10 = 30。得出平均值：(24 + 33 + 24 + 33 + 30) / 5 = 29。理论上的计算公式，进一法取整(事务数量 / 5) / 容器数量 * 60。符合预期。如图8

图8

12、模拟出 8 条任务。事务ID为 57、58、59、63、64、65、68、69 的同步时间(分钟)分别为：11、12、13、12、11、12、11、12 。事务ID为 57、58、59、63、64、65、68、69 的同步次数分别为：21、22、22、19、17、5、17、17 。事务ID为 57、58、59、63、64、65、68、69 的同步频率分别为：11 * 60 / 21 = 31、12 * 60 / 22 = 33、13 * 60 / 22 = 35、12 * 60 / 19 = 38、11 * 60 / 17 = 39、12 * 60 / 5 = 144、11 * 60 / 17 = 39、12 * 60 / 17 = 42。得出平均值：(31 + 33 + 35 + 38 + 39 + 144 + 39 + 42) / 8 = 50。理论上的计算公式，进一法取整(事务数量 / 5) / 容器数量 * 60。符合预期。如图9

图9