Redis应用及数据同步问题

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key-value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。

　　1. 按照我们一般的使用Redis的场景应该是这样的：

　　也就是说：我们会先去redis中判断数据是否存在，如果存在，则直接返回缓存好的数据。而如果不存在的话，就会去数据库中，读取数据，并把数据缓存到Redis中。

　　适用场合：如果数据量比较大，但不是经常更新的情况(比如用户排行)

　　2. 而第二种Redis的使用，跟第一种的情况完成不同，具体的情况请看：

　　这里我们会先去redis中判断数据是否存在，如果存在，则直接更新对应的数据(这一步会把对应更新过的key记录下来，比如也保存到redis中比如：key为：save_update_keys【用lpush列表记录】)，并把更新后的数据返回给页面。而如果不存在的话，就会去先更新数据库中内容，然后把数据保存一份到Redis中。后面的工作：后台会有相关机制把Redis中的save_update_keys存储的key，分别读取出来，找到对应的数据，更新到DB中。

　　优点：这个流程的主要目的是把Redis当作数据库使用，更新获取数据比DB快。非常适合大数据量的频繁变动(比如微博)。

　　缺点：对Redis的依赖很大，要做好宕机时的数据保存。(不过可以使用redis的快照AOF，快速恢复的话，应该不会有多大影响，因为就算Redis不工作了，也不会影响后续数据的处理。)

　　难点：在前期规划key的格式，存储类型很重要，因为这会影响能否把数据同步到DB。

 

关于缓存一致性非常清晰的文章，严重推荐阅读：

https://blog.kido.site/2018/11/24/db-and-cache-preface/

 

转载如下：

一般来说，对于一个新的业务，一般会经历这几个阶段：

阶段1：单库阶段

读写流量都比较小，这个时候所有的读写操作都在主库就ok了
这个时候，从库可能只是用来灾备
风险分析：从数据一致性角度来说没有风险，全走主库美滋滋~

阶段2：多库阶段

阶段2.1：

单库扛不住了，这个时候就会考虑到分库分表了，通过增加数据库的方式，把单库的QPS降下来
风险分析： 从数据一致性角度来说没有风险，全走主库依然美滋滋~

阶段2.2：

读流量增加，主库的读QPS偏高，这个时候我们就想着把从库得利用起来，于是读写分离：写主库，读从库
风险分析：读从库就意味着，读到的数据可能不是最新的，在实时性要求比较高的业务中是不能接受的，那应该如何解决呢？由于”DB主从一致性”不是本系列讨论的重点，所以这里推荐一篇文章,它介绍了几种比较不错的解决方案，感兴趣的大家可以去读一下：DB主从一致性架构优化4种方法

阶段3：数据库+缓存

对于互联网公司来说，大部分业务都面临着读多写少的情况（如果你写都有压力的话，那你做的业务一定很赚钱吧），而数据库资源是极其宝贵的，所以我们没有办法一味的添加从库，或者说不断的增加分库分表来解决，一是因为老板不会同意，二是不断分库分表的话，数据迁移过程也是高风险的。
所以，这个时候我们一般会通过添加的缓存的方式，来解决读压力
风险分析：缓存与数据库数据一致性问题

这就引出本系列文章，想要讨论的问题：缓存与数据库数据一致性问题，在提出解决方案之前，我们应该分析自己当前的业务和架构，看看自己的要达到的目标是什么？不同的方案解决的问题是不一样的

所以，你的业务和目标是怎样的呢？

• 你是要求最终一致性、还是强一致性？
• 你对缓存一致性的要求到底有多高？延迟1ms行不行？延迟1min行不行？
• 你当前是单库单表？还是多库多表？
• 你缓存的数据结构是怎样的？是否存在多表合并？是否存在多行合并的情况？甚至多库合并的情况？
• 该如何容灾?更新、删除缓存失败你能不能接受？写数据库失败怎么办？
• 如果删除缓存失败，你还允不允许更新数据库？
• ……