日常踩坑--redis 集群

最近在做一个银行业的软安全项目，前台是SDK模式，嵌入到手机银行APP中；后台是JAVA开发的web服务，部署在内网。软件架构为weblogic+oracle+redis结构，2台应用服务器做双活，应用服务器上部署weblogic+redis。redis主要保存一些临时有效数据（验证码、申请记录等）。

产品确实是个成熟产品，但是与现场要求结合起来就产生了各种坑。

先说redis 集群的坑，我们通用的产品采用的sentinel模式，这个项目客户愣是觉得sentinel模式下只有master真正在工作，压力集中在master上会出问题，不是真正意义上的双机，强制要求使用cluster模式（用户量不上百万级的系统，日活不超过百万，巅峰并发估计也不会上百）。

吐槽暂停，按照redis cluster的部署方案，现场2台应用服务器（61、62）按三主三从模式创建集群。集群创建完成后测试业务无问题。后续的业务调整及测试中，各个坑就接踵而至了。

坑1：add notes

sit环境测试没有问题，用户要求编写部署手册，然后按照部署手册进行部署验证。显然用户是不会再弄一台服务器来验证部署手册了，把61上的环境清除（测试工作持续进行中，只能清除一台验证，另外一台还要提供服务），重新部署，将61上的redis服务通过add notes的方法添加到集群。坑就此埋下。

压力测试时发现61机器的redis进程cpu占用率几乎为0，连接上redis集群检查nodes状态：./src/redis-cli -c -h **** -p 6379

槽点全部分配在62机器的3个服务上（此时没细看，不然可以跳过下面这个小坑），果断干掉其中一个服务，等master切换后重新启动服务。结果应用直接挂了，因为redis的槽点不能全覆盖，61机器的3个服务没有接管被干掉服务的槽点。这时再仔细检查nodes状态，发现了问题：61机器上的三个服务全部都是MASTER!!!

原来redis cluster在add nodes之后新增加的节点自动为master，此时添加工作其实还没完成，需要手动将新增的节点改变成现有master的salve（捣鼓了几次没有成功，直接抹掉了62上的服务，重新创建了cluster，待有空再研究一下）。

坑2：模糊查询

临上线前，用户突发奇想要修改一个需求，要求支持同一个用户多少设备的申请（现状是同一个用户在多个设备上申请时只能保留一个记录，原因是redis的key设计为APP+用户号的模式了，影响范围就是用户有多个设备时需要一个个的完成绑定操作）。

改吧，key设计为APP+用户号+设备号，柜面系统在用户办理业务时需要查询待认证设备列表，此时我们需要去redis中查询出所有此用户申请的记录，模糊查询keys APP+用户号+*，做完后开发自测了一下么有问题，提交更新sit环境（坑已挖好，坐等跳了）。

sit环境更新完之后自测了一下（使用jmeter测试，反正性能测试的时候脚本都是现成的了），突然发现柜面无法正常获取设备列表了，查不到记录。

排查代码，日志中将redis的key正常打印了，后面获取返回的结果为空。

莫名其妙的问题，连接至redis的其中一个master后keys *看了下，的确没有记录；再试，有记录；再试，没有记录。一会有一会没有实在神奇，想到redis cluster有三个master，都连上再跟踪，都有记录了。原来cluster是根据将key值进行hash算出来槽值再根据槽的分布决定写到哪个master上面。

试一下cluster keyslot app_no_*，发现了神坑：cluster不支持模糊查询！！！key不能确定的话redis不知道去哪个master去查询。

改成遍历所有的master去get后解决问题。