最近几个月非常忙，所以很少有时间写博客，这几天终于闲了一些，于是就在整理平时的一些笔记。恰好这几天Redis服务器发生了问题，就记录一下。
我司有两款分别是2B和2C的App，类似于阿里旺旺的卖家版和买家版，里面有一个聊天的功能模块。双方可以通过这个功能聊天。内部通讯使用了环信，只是将本地账号和环信账号进行了关联。其他的信息，比如用户基本信息，好友关系，群组关系等存在Redis中，为防止Redis出现问题导致数据丢失（尽管配置了持久化），同时使用消息队列将数据写入SQLServer中进行了冗余。这是一种Redis的典型使用场景，从速度和效率上满足要求。
线上环境一直运行正常，但是在上周日（一个本该休息的日子），领导打电话过来说线上环境的用户登录不了，无法聊天，没有群相关信息。我想估计是Redis出现了问题，让领导不要着急，先让运维看看服务是否还在运行，不行的话，把Redis重启一下，因为之前设置过持久化，数据应该不会丢失。于是继续陪夫人吃饭，看电影。
到了晚上，还是打电话过来说有问题，没办法只有来公司一趟。打开机器用RedisClient连Linux环境上的Redis，发现里面的数据全没了，只有几个新注册的孤零零的用户在里面，老用户全没了，我当时惊呆了，以为是运维那边没搞好，是重启的整个服务器而不是重启的Redis，可能是Redis没有及时保存把数据给弄丢了。看到现象之后跟领导电话告知目前的现象和建议的解决方案，在授权下，重新把用户相关数据从SQLServer同步到了Redis中，关键的数据还好没丢失，然后让测试简单测试了一下，一切正常就没有太在意。而且由于Redis是安装在Linux上的，是由运维同事维护的，出问题了我这边也查不了，于是就回去了。
但是事情远没有那么简单，星期一的时候，领导又打电话过来说聊天又不能用了，比较急说要赶紧处理，我说好，于是不紧不慢的收拾好出门去公司。心里非常不爽，前段时间加班太猛，周一周二全公司开发都调休放假的。就我一个开发的来到公司之后，打开远程又发现Redis里面的数据全没了。于是又从SQLServer把数据同步到了Redis里，然后检查代码，把除了和聊天相关之外的其他逻辑，比如Redis定时同步服务相关的可能会影响到的地方都暂停了。因为前段时间做了一次重构，担心是代码导致数据丢失，搞完了之后就回去了。
然而好景不长，消停了一天没出问题。今天早上过来上班，领导走过来语重心长的说，聊天又登不上了，上去一看，Redis里面的数据又没了。正好运维的同事也在，也就一起找下存在的漏洞和可能的原因。
原因前几天无意在微博上看到了乌云平台发的一条漏洞信息：
然后意识到是不是Redis没有设置密码访问，导致产生了这个漏洞被利用和攻击了。于是自查，发现了如下内容：
里边多了一个名为crackit的字符串，并且db0这个库是没有使用了的，现有的数据和逻辑都在db1上，刚打开的时候，db1是空的，上图是我重新同步过数据之后的结构。
对比乌云报的漏洞的最后一部分:
这简直就是一模一样啊。并且运维那边发现redis的持久化文件被写到了authorized_keys文件中：
确认被攻击之后，于是开始着手修复。之前在开发的时候，其实是有考虑给Redis加访问密码的，不知道后来太忙了，竟然给忘了，也想着公司比较小，应该不会被黑之类的，没想到这次就撞上了。
解决方法解决方法当然是给Redis加密码，然后在访问的时候，设置密码访问。
最初，访问Redis的客户端我们使用的是ServiceStack.Redis，我之前也写过几篇Redis相关的文章。 由于考虑到授权的原因，使用的是2.0版本的dll，在其API中，从签名看，没有地方可以设置密码：
这个地方只能设置主机名称和端口号。
于是在使用中，比如下面这个删除群组的操作，RedisHelper类是对ServiceStack.Redis的一个封装类，只需要设置主机和端口号：
public static bool DeleteGroup(string groupId) { lock (lockDeleteGroup) { bool result = true; using (RedisHelper redis = new RedisHelper(HOST, PORT)) { var group = redis.GetWhereObj<GroupTable>(GROUPTABLE, x => x.GroupId == groupId); group.Is_Deleted = true; result = redis.Update<GroupTable>(GROUPTABLE, x => x.GroupId == groupId, group); } return result; } }后面为了安全考虑，需要给Redis设置个密码，于是下载了最新版本的4.0的ServiceStack.Redis，这个是商业化版本的，使用中发现，是有限制的，在其下载页面最下角也有说明：
每小时只能请求6000次，这显然不能满足要求。除了以上限制之外，在使用过程中也出现过一些相当诡异的问题，比如通过Id查找的时候，其只能在1k条范围内进行查询等等，当然，也有可能是因为使用不正确，考虑到以上原因，加之之前的数据组织和结构设计不合理，于是决定重构。
相关文章
精彩导读
热门资讯
关注我们
