redis宕机导致数据丢失的重大生产事故总结

这周五周六经历一次严重的redis宕机导致数据丢失的严重生产数据，并导致了10小时的停服。算是工作以来经历的最大生产事故，今天做一个全面总结，也算是吃一堑长一智。

事情经过

随着我们业务量不断增加，我们线上环境的redis内存逐渐吃紧。然后（2022-07-22）周五的时候，运维说他们要进行redis升级，他们先升级从库，以前为了提升主库性能，他们把redis的数据rdb备份放在了从库。因为放在主库的话需要消耗主库的CPU和内存空间，从而会影响主库的性能。而从库升级内存需要需要停机，所以他们临时把rdb备份临时放到了主库。结果从库升级完后，回来发现主库因为内存不足，rdb备份都是是不成功的，而从库升级这段时间主库都是有的业务数据写入进来的，所以从从库停机开始往后的数据都没有备份到磁盘。

这时摆在我们面前就两条路，一是舍弃这几分钟的数据，直接主从切换，让从库继续运转。二是让主库继续运行，然后想办法后续把增量数据同步到从库里去。经过评估，这丢失几分钟的数据，存在一些关键数据，比如盲盒的奖池，比如水浒当前轮次的押注数据，这些数据都是无法接受几分钟的数据丢失的。所以在当时我们认为选择方案二更稳妥。

基于方案二，我们有讨论了几种落地方案:

1. 删除主库中的一些长时间未使用（近3个月未使用的）的数据，腾出内存，让主库能够进行rdb备份。但但删除后发现，被删除的内存空间变成了碎片空间存在于redis服务中，无法进行内存释放。所以rdb备份仍然不能成功。
2. 业务层面进行双写，让业务服务器在接下来的增量数据同时写入主库和从库，这样从库的数据就能和主库的都能拥有最新数据，等运行一段时间后（一周或者两周），在把读操作从主库迁移到从库，这样（丢失的那部分数据已经是较长时间之前的）对用的影响就不会那边么大的。但是后来分析，这个方案有问题，一是实现起来比较难，如果去每个业务代码里增加双写逻辑，工作量太大；或者通过对redis操作类进行子类重写，然后注入的时候注入我们重写的子类，这样我们只需要在子类里把redis所有的命令都重写成双写方式就好了；这种方式工作量相对较小，但是对于对于一些操作有问题，比如我们的自增操作，双写时候，由于主库和从库的原始数据不一样，那自增之后，值还是不一样，并且这种不一致会一直保持下去。这是如果我们主库自增，然后把自增结果set到从库，这时又会存在并发问题。所以这个方案最后也行不通。
3. 找一个活跃用户很少的时间，停服维护，停机后，就不会有新数据，然后把主库的数据同步到从库，然后进行主从切换，再启动服务。

最终由于方案一和方案二的无法落地，我们只能选择方案三，所以根业务部门沟通后我们在次日（2022-07-23）凌晨六点到七点进行停服维护。

我们把原本凌晨6点到7点之间的脚本，提前执行，然后写了一个redis基于内存迁移数据的python脚本：

## 安装redis库的命令： sudo pip3 install redis -i https://pypi.doubanio.com/simple
## -i 表示指定下载镜像地址，如果不指定的花，redis这个库在国外，可能下载不成功

import redis
import time

old_conn = redis.from_url('redis://:xxxxx@xxxx-xxxx.m.com:111')
new_conn = redis.from_url('redis://:xxxx@xxxxx.xxx.xxx.xxx:111')
## 限制数量（为0表示不做限制）
limit_cnt = 0
debug_console = True

## 开始游标
start_cursor = 0
total_cnt = 0
start_time = time.time()
print("开始同步")
while(start_cursor >= 0 and (limit_cnt <= 0  or total_cnt < limit_cnt)):
    ## 获取key
    info = old_conn.scan(start_cursor,"*",500)
    ## 获取key列表
    items = info[1]
    for it in info[1]:
        if(limit_cnt > 0 and total_cnt >= limit_cnt):
            break
        ## 获取key原本的过期时间
        ttl = old_conn.pttl(it)
        if(ttl == -1):
            ## -1表示这个key没有过期时间
            ttl = 0
        elif(ttl == -2):
            print("上一瞬间过期的key：", it)
            continue
        if(debug_console):
            print("迁移key：", it)        
        ## 读取二进制数据
        value = old_conn.dump(it)
        ## 删除新库中的老数据
        new_conn.delete(it)
        ## 写入到新的redis中去
        new_conn.restore(it,ttl,value)
        total_cnt= total_cnt + 1
    new_cursor = info[0]
    if(new_cursor == 0):
        ## 表示已经结束了
        start_cursor = -1
    else:
        start_cursor = new_cursor

print("迁移完成,累计迁移key数量：",total_cnt,"。累计耗时:", time.time() - start_time, "ms")


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

但是后来运维同学发现了阿里云提供的一个迁移工具。所以最终这个脚本没有用到。然后次日凌晨我们按时停服维护，然后运维开始用阿里云工具迁移数据。结果该工具过于吃内存（可能是因为读取大key导致的）导致redis主库内存吃紧，最后系统把redis主库的进程给杀了。从而导致没有备份的数据彻底丢失了。

之后我们就开始了漫长的恢复数据的时间，我们只能去分析业务，然后根据mongo里的数据，把一些能恢复的核心的数据进行了恢复，原本预计七点重启服务的，结果一直到了下午四点才把服务再次起气来，导致了一次10小时停服的严重生产事故。服务重启后因为还有一些数据没有恢复，所以不断地有用户反馈问题，进行后续的问题处理。并且写数据恢复脚本的过程中，盲盒业务只考虑到了用户在丢失数据时间内购买的盲盒卡，而没有考虑到用户使用的盲盒卡，最后恢复盲盒卡数据的时候，多发了用户盲盒卡，虽然最后及时关停盲盒功能，追回了部分损失，但是仍然产生了不少额外的经济损失。

总结

1. 服务端因其本身的特性，就存在持续开发的问题。如果我们做前端，一个功能上去正常运转后，那基本就是能一直正常运转的。但是服务端不行，特别是互联网公司，因为用户体量的和业务复杂度带来的数据，一直在增加，而数据的增加就会对服务器稳定性不断带来冲击，并且老数据的对新业务的也会产出各种限制（因为新的业务要兼容老的数据）。而且比如用户手机用久了，内存吃紧了，自己杀进程重启一下就好了，但是服务端一般都要尽可能避免停服，因为一旦停服平台所有的在线用户都会被影响。但是作为一个业务导向的公司，我们几乎不关注这种复杂度和数据量增加对系统稳定性带来的冲击，每次都是被逼到角落里，发现不得不去处理的时候才去着手处理，有时候顺利处理完成，有时候比如这次就是在墙角里翻车了。我们可能关注点在翻车本身，其实这个翻车的隐患一直都在不断积累。如果我们能花更多时间去关注这种业务持续发展对服务器稳定性的影响，就能从根本去避免这次问题。比如我们能早点关注到redis的内存在增加，早点规划，那怎么至于到今天内存吃紧到最后把redis服务器逼停的地步。所以我们要去搭建这种基础监控平台并利用好。我们的mongo，redis，mq，xxl-job，xxl-job脚本的执行效率，业务服务器本身的负载，这些都需要得到合理的监控（如果没有监控平台更要早日规划监控设施的搭建），这样未来才能把问题消灭在萌芽。
2. 运维同学在从库备份一开始，没有注意到redis主库无法完成rdb备份，这本身也是流程上的失误，可能以前没有一个redis服务器升级操作规范，导致了这个失误。或者以前的规范里没有这一条注意事项，那经此时间，也需要重新梳理这个操作规范。生产环境毕竟是高风险的东西，一切最好都有规范的流程操作作为指导，才能尽可能降低风险。
3. 在数据迁移前，不管是使用我们自己的脚本，还是使用阿里云的工具，其实都应该进行严格的测试。虽然我们也都进行了测试，运维同学还对阿里云的工具，用线上同等体量的数据进行了测试，但是最后忽略了主库redis内存本身吃紧一个要素，测试的redis服务器没有内存吃紧的问题。这也就是导致数据丢失的直接原因。但是测试点想的不够全面，这个事情其实只能说这次经历了，做好总结下次避免了。毕竟思考问题，谁都未必能想的最全面，我们只能总结过去的问题，避免未来再次发生。
4. redis作为一个缓存数据库，我们本身也不应该给他赋予如此多的核心数据的存储功能，redis应该回到的原始职能。作为一个不带事务，并且数据只能通过备份，没有崩溃恢复能力的缓存数据库，因为我们过去的各种偷懒，让他被赋予了过多的职能。这也是这次redis崩溃后需要大量手动恢复数据，导致停服时间过长的最重要的原因。我们很多时候，为了图简单图快（redis就一个命令就好了，存到mongo还要写较长的语句，还要考虑表结构设计，还要考虑索引），把大量数据都存在了redis，这个本身就是设计上的偷懒和失误。我们在功能设计时，其实应该去考虑，该数据的重要性，对于重要数据还是应该存储到mongo里，比如我们的用户盲盒卡，比如每一轮的水浒押注数据，比如用户的大小喇叭，这些都应该存储到mongo中，这样其实就算redis宕机了，里面也是缓存，或者可的舍弃数据，那还怕啥呢，（那这时候杠精可能要说了，那你mongo或者mysql宕了呢，mongo和mysql是具备崩溃恢复能里的。就算突然断电了，也是能进行数据恢复的），直接重启来不就好了。redis作为一个缓存数据库，我们应该使用他原本的职能。比如热点数据的缓存，比如分布式锁，或者一些非核心数据的存储，比如房间麦位状态啊（房间异常了，重新开播就正常了）。
5. redis的业务拆分。其实如果早期我们能够按业务对redis进行一个拆分，那宕机的时候，也不至于影响到全部业务。
6. 自己在数据恢复过程中，由于对被恢复数据的思考不全面，导致部分用户多发了盲盒卡，这个其实算是整个事件的插曲了，主要是因为这件事造成了额外的经济损失。其实自己挺内疚的，但就事论事分析一下，在那个高情绪压迫和时间紧迫的环境下，大量的数据需要从各种业务角度去分析并通过写脚本去实现恢复，并且由于时间紧张也没有测试参与对我们的脚本代码进行，在这种情况下要求处理问题的人员百分百没有任何失误其实也是不现实的，所以其实出现一点失误是在情理之中，只是这个失误刚好出现在会导致经济损失的业务上了，所以也不能太妄自菲薄。就像上面的第四点一样，对于事情的思考的全面性，其实换了任何一个人来都是不能保证百分百没有失误的，只能是经历这一次，汲取教训，下次避免。同样这里也是，未来对于有经济影响的业务应该持有更加谨慎程度，对于货币类的数据，都是需要从增加和扣减两个角度去思考的，未来要避免再次发生这种情况。