一、 测试目的
测试Redis主从热备，在key随机大小的情况下性能如何，其中主机不带持久化，从机带持久化，且写、改在主机上操作，读则在从机上操作。
二、 测试环境
1、 网络环境
如图1所示，42、45、43均连接至千兆交换机，其中42为服务端master，45为服务端slave，43为客户端：
图1
2、 硬件环境
IP
| 型号
| OS
| CPU
| 内存
| 硬盘
| 网卡
| 用途
|
192.168.0.42 | HP刀片 | RedHat6.2 x86_64 | Intel(R) Xeon(R) E5410 @ 2.33GHz 8核 | 16G | 68G | 1000Mb/s | 被压主机 |
192.168.0.45 | HP刀片 | RedHat6.2 x86_64 | Intel(R) Xeon(R) E5410 @ 2.33GHz 8核 | 16G | 68G | 1000Mb/s | 被压从机 |
192.168.0.43 | HP刀片 | RedHat6.2 x86_64 | Intel(R) Xeon(R) E5410 @ 2.33GHz 8核 | 16G | 68G | 1000Mb/s | 加压机 |
3、 软件环境
软件名称
| 软件版本
| 是否开源
|
redis | v2.6.5 | 是 |
三、 测试结果
在2到100字节范围内生成随机大小的key，加上10字节的value组成每条数据记录内容；每次操作线程数为50个，每线程10万条记录，在老数据基础上进行测试；老数据基础分别为7000万、7500万、8000万条……，依次类推每次测试增长500万条，分别测试insert、select、update情况；
Redis主从热备过程如下：
1) Slave与Master建立连接，然后发送SYNC命令；
2) Slave无论是第一次或者重新连接，Master都会启动一子进程，将数据库快照保存到.rdb文件中，同时Master主进程收集新的写命令并缓存；
3) 子进程完成写文件后退出，Master再把文件发送给Slave，Slave将文件保存到磁盘上，完了之后再加载到内存中；
4) 接着Master再把缓存的命令转发给Slave，后续Master将收到的写命令都同步发送给Slave；
5) 如果Master同时收到多个Slave发来的同步连接命令，Master只会启动一个子进程来写数据库镜像，然后再发送给所有的Slave；
注：Slave第一次或者重新连接到Master，都会进行全量同步数据，之后如果Master有新数据，才进行增量同步，且Slave在同步数据过程中不接受任何操作请求。
1、 insert操作性能情况
1) 在老数据基础上，进行50个客户端并发，每客户端操作100,000次写，平均用时如图2-1、图2-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 74794.32 | 74471.25 | 74460.16 | 73540.23 | 73583.52 | 6777.64 |
slave
|
图2-1
图2-2
说明：纵轴为平均用时（单位：次/秒），横轴为老数据基础（单位：千万）；
2) CPU使用情况，如图3-1、图3-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 86.71 | 95.20 | 92.46 | 93.90 | 93.85 | 10.18 |
slave
| 21.93 | 31.47 | 26.53 | 29.78 | 29.01 | 0.99 |
图3-1
图3-2
说明：纵轴为平均占用单个CPU百分比，横轴为老数据基础（单位：千万）；
3) MEM使用情况，如图4-1、图4-2示：
| 7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
|
master
| 68.11 | 72.16 | 76.42 | 80.56 | 84.78 | 84.87 |
slave
| 68.09 | 72.11 | 76.45 | 80.52 | 84.79 | 75.52 |
图4-1
图4-2
说明：纵轴为占用内存平均百分比，横轴为老数据基础（单位：千万）；
4) 每秒页面错误，如图5-1、图5-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 81.06 |
slave
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 2.40 |
图5-1
图5-2
说明：纵轴为每秒产生的页面错误数，横轴为老数据基础（单位：千万）；
5) 磁盘IO读情况，如图6-1、图6-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 1986.25 |
slave
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 75.99 |
图6-1
图6-2
说明：纵轴为磁盘IO读的数量（单位：kB/s），横轴为老数据基础（单位：千万）；
6) 磁盘IO写情况，如图7-1、图7-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.82 | 0.73 | 0.64 | 0.83 | 1.06 | 0.57 |
slave
| 518.44 | 2317.03 | 1437.87 | 255.83 | 667.09 | 0.62 |
图7-1
图7-2
说明：纵轴为磁盘IO写的数量（单位：kB/s），横轴为老数据基础（单位：千万）；
2、 select操作性能情况
1) 在老数据基础上，进行50个客户端并发，每客户端操作100,000次读，平均用时如图8-1、图8-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| ||||||
slave
| 94984.80 | 94304.04 | 93057.88 | 92165.90 | 94589.48 | 68728.52 |
图8-1
图8-2
说明：纵轴为平均用时（单位：次/秒），横轴为老数据基础（单位：千万）；
2) CPU使用情况，如图9-1、图9-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
slave
| 79.45 | 90.41 | 84.83 | 89.12 | 93.42 | 70.92 |
图9-1
图9-2
说明：纵轴为平均占用单个CPU百分比，横轴为老数据基础（单位：千万）；
3) MEM使用情况，如图10-1、图10-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 69.99 | 74.34 | 78.45 | 82.68 | 86.92 | 53.48 |
slave
| 69.97 | 74.21 | 78.43 | 82.66 | 82.43 | 90.93 |
图10-1
图10-2
说明：纵轴为占用内存平均百分比，横轴为老数据基础（单位：千万）；
4) 每秒页面错误，如图11-1、图11-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
slave
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 39.55 |
图11-1
图11-2
说明：纵轴为每秒产生的页面错误数，横轴为老数据基础（单位：千万）；
5) 磁盘IO读情况，如图12-1、图12-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
slave
| 1.55 | 0.00 | 0.00 | 0.00 | 0.00 | 1261.71 |
图12-1
图12-2
说明：纵轴为磁盘IO读的数量（单位：kB/s），横轴为老数据基础（单位：千万）；
6) 磁盘IO写情况，如图13-1、图13-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.48 | 0.87 | 0.68 | 0.83 | 0.80 | 0.75 |
slave
| 0.78 | 0.80 | 0.90 | 0.67 | 0.76 | 0.62 |
图13-1
图13-2
说明：纵轴为磁盘IO写的数量（单位：kB/s），横轴为老数据基础（单位：千万）；
3、 update操作性能情况
1) 在老数据基础上，进行50个客户端并发，每客户端操作100,000次改，平均用时如图14-1、图14-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 65019.51 | 65163.56 | 64566.12 | 65265.63 | 64366.63 | 28851.70 |
slave
|
图14-1
图14-2
说明：纵轴为平均用时（单位：次/秒），横轴为老数据基础（单位：千万）；
2) CPU使用情况，如图15-1、图15-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 92.68 | 92.59 | 88.38 | 92.73 | 91.99 | 43.33 |
slave
| 29.94 | 25.35 | 27.00 | 27.47 | 27.75 | 3.42 |
图15-1
图15-2
说明：纵轴为平均占用单个CPU百分比，横轴为老数据基础（单位：千万）；
3) MEM使用情况，如图16-1、图16-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 70.20 | 74.56 | 78.46 | 82.72 | 87.17 | 61.02 |
slave
| 69.97 | 74.21 | 78.43 | 82.66 | 82.43 | 86.91 |
图16-1
图16-2
说明：纵轴为占用内存平均百分比，横轴为老数据基础（单位：千万）；
4) 每秒页面错误，如图17-1、图17-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 94.72 |
slave
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 64.50 |
图17-1
图17-2
说明：纵轴为每秒产生的页面错误数，横轴为老数据基础（单位：千万）；
5) 磁盘IO读情况，如图18-1、图18-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 2067.77 |
slave
| 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 2036.16 |
图18-1
图18-2
说明：纵轴为磁盘IO读的数量（单位：kB/s），横轴为老数据基础（单位：千万）；
6) 磁盘IO写情况，如图19-1、图19-2示：
7.00
| 7.50
| 8.00
| 8.50
| 9.00
| 9.50
| |
master
| 0.68 | 0.58 | 0.51 | 0.82 | 0.87 | 0.70 |
slave
| 797.51 | 191.29 | 147.11 | 0.92 | 1356.34 | 9.19 |
图19-1
图19-2
说明：纵轴为磁盘IO写的数量（单位：kB/s），横轴为老数据基础（单位：千万）；
四、 分析及结论
1、 insert操作性能情况
1) 相同的数据模型，相同的服务器环境，在达到内存上限前，Redis不带持久化，能保存的热数据要比带持久化时多些，前者能保存约9千万条，后者能保约8千万条；
2) 在达到内存上限前，Redis带主从热备写性能要比不带时低些，前者约7万4千条每秒，后者约7万8千条每秒；
3) Redis主机在达到内存上限后，写性能会急剧下降；
4) Redis主机平均占用单个CPU百分比，在达到内存上限前一直稳定在90%左右，而从机一直稳定在29%左右；达到内存上限后，二者均受内存swap每秒产生大量页面错误影响，CPU使用率会急剧下降；
5) Redis主从机内存占用均随着写入数据的逐渐增多而增大，但达到内存上限后，二者均受内存swap每秒产生大量页面错误影响而持续下降，从机还受子进程dump数据竞争内存而下降更明显；
6) Redis主从机在达到内存上限后，由于需要把部分数据转到交换分区，均会每秒产生大量的页面错误；
7) Redis主从机在达到内存上限前，均没有磁盘IO读操作，之后就有明显的磁盘IO读操作，尤其主机最明显；
8) 在整个插入数据过程中，Redis主机磁盘IO写操作不是很明显，而从机磁盘IO写操作很明显且不规则；
2、 select操作性能情况
1) Redis主从热备情况，数据可以从Slave读出，从而分担Master压力，性能约9万4千条每秒，而单机情况下读性能约8万5千条每秒；
2) Redis主机在达到内存上限后，读性能会急剧下降；
3) Redis从机平均占用单个CPU百分比，在达到内存上限前，一直稳定在90%左右，之后受内存swap每秒产生大量页面错误影响而持续下降；
4) Redis主从机内存占用均随着写入数据的逐渐增多而增大，但达到内存上限后，二者均受内存swap每秒产生大量页面错误影响而持续下降；
5) Redis从机在达到内存上限后，由于需要把部分数据转到交换分区，会每秒产生大量的页面错误；
6) Redis从机在达到内存上限前，没有磁盘IO读操作，之后就有明显的磁盘IO读操作；
7) 在整个查询数据过程中，Redis从机磁盘IO写操作不是很明显且不规则；
3、 update操作性能情况
1) 在达到内存上限前，Redis带与不带主从热备，改性能都差不多，约6万5千条每秒；
2) Redis从机在达到内存上限后，改性能会急剧下降
3) Redis主机平均占用单个CPU百分比，在达到内存上限前一直稳定在90%左右，而从机一直稳定在29%左右；达到内存上限后，二者均受内存swap每秒产生大量页面错误影响，CPU使用率会急剧下降；
4) Redis主从机内存占用均随着写入数据的逐渐增多而增大，但达到内存上限后，二者均受内存swap每秒产生大量页面错误影响而持续下降；
5) Redis主从机在达到内存上限后，由于需要把部分数据转到交换分区，均会每秒产生大量的页面错误；
6) Redis主从机在达到内存上限前，均没有磁盘IO读操作，之后就有明显的磁盘IO读操作；
7) 在整个修改数据过程中，Redis主机磁盘IO写操作不是很明显，而从机磁盘IO写操作很明显且不规则；
五、 后续测试及开发建议
1、 测试建议
1) 是否可以加入删除情况测试；
2、 开发建议
1) 在达到内存上限后，主从机性能都会急剧下降；
2) 如果需要持久化，最好把持久化设置在Slave上，且Master与Slave最好在同一局域网内；
3) Slave第一次或重新连接Master，如果Master原库数据量大，主从数据同步时，会严重影响Master性能；
作者：廖诚
