别再问了-数据库与缓存一致性问题今天全整齐活了！ (别再问了表情包)

Redis 拥有高性能的数据读写功能，被我们广泛用在缓存场景，一是能提高业务系统的性能，二是为数据库抵挡了高并发的流量请求。

把 Redis 作为缓存组件，需要防止出现以下的一些问题，否则可能会造成生产事故。

今天跟大家一起深入探索缓存的工作机制和缓存一致性应对方案。

在本文正式开始之前，我们需要先取得以下两点的共识：

1）缓存必须要有过期时间；

2）保证数据库跟缓存的最终一致性即可，不必追求强一致性。

1. 什么是数据库与缓存一致性

3. 旁路缓存下的一致性问题分析

3.1 先更新缓存，再更新数据库

3.2 先更新数据库，再更新缓存

3.3 先删缓存，再更新数据库

3.4 先更新数据库，再删缓存

4. 一致性解决方案有哪些

一、什么是数据库与缓存一致性

反推缓存与数据库不一致：

为何会出现数据一致性问题呢？

把 Redis 作为缓存的时候，当数据发生改变我们需要双写来保证缓存与数据库的数据一致。

数据库跟缓存，毕竟是两套系统，如果要保证强一致性，势必要引入 2PC 或 Paxos 等分布式一致性协议，或者分布式锁等等，这个在实现上是有难度的，而且一定会对性能有影响。

如果真的对数据的一致性要求这么高，那引入缓存是否真的有必要呢？

二、缓存的使用策略

在使用缓存时，通常有以下几种缓存使用策略用于提升系统性能：

所谓「旁路缓存」，就是读取缓存、读取数据库和更新缓存的操作都在应用系统来完成，业务系统最常用的缓存策略。

1）读取数据

优点

;.() () {;}  {//缓存缺失, 从数据库获取数据();.()}

缺点

由于数据仅在缓存未命中后才加载到缓存中，因此初次调用的数据请求响应时间会增加一些开销，因为需要额外的缓存填充和数据库查询耗时。

2） 更新数据

使用 cache-aside 模式写数据时，如下流程。

使用 cache-aside 时，最常见的写入策略是直接将数据写入数据库，但是缓存可能会与数据库不一致。

我们应该给缓存设置一个过期时间，这个是保证最终一致性的解决方案。

如果过期时间太短，应用程序会不断地从数据库中查询数据。同样，如果过期时间过长，并且更新时没有使缓存失效，缓存的数据很可能是脏数据。

删除缓存使缓存数据失效

性能问题

当缓存的更新成本很高，需要访问多张表联合计算，建议直接删除缓存，而不是更新缓存数据来保证一致性。

安全问题

在高并发场景下，可能会造成查询查到的数据是旧值，具体待会会分析。

当缓存未命中，也是从数据库加载数据，同时写到缓存中并返回给应用系统。

虽然 read-through 和 cache-aside 非常相似，在 cache-aside 中应用系统负责从数据库获取数据和填充缓存。

而 Read-Through 将获取数据存储中的值的责任转移到了缓存提供者身上。

Read-Through 实现了关注点分离原则。代码只与缓存交互，由缓存组件来管理自身与数据库之间的数据同步。

与 Read-Through 类似，发生写请求时，Write-Through 将写入责任转移到缓存系统，由缓存抽象层来完成缓存数据和数据库数据的更新，时序流程图如下：

Write-Through 的主要好处是应用系统的不需要考虑故障处理和重试逻辑，交给缓存抽象层来管理实现。

单独直接使用该策略是没啥意义的，因为该策略要先写缓存，再写数据库，对写入操作带来了额外延迟。

当Write-Through 与 Read-Through 配合使用，就能成分发挥 Read-Through 的优势，同时还能保证数据一致性，不需要考虑如何将缓存设置失效。

这个策略颠倒了 Cache-Aside 填充缓存的顺序，并不是在缓存未命中后延迟加载到缓存，而是在数据先写缓存，接着由缓存组件将数据写到数据库。

优点

缺点

不经常请求的数据也会写入缓存，从而导致缓存更大、成本更高。

这个图一眼看去似乎与 Write-Through 一样，其实不是的，区别在于最后一个箭头的箭头：它从实心变为线。

这意味着缓存系统将异步更新数据库数据，应用系统只与缓存系统交互。

应用程序不必等待数据库更新完成，从而提高应用程序性能，因为对数据库的更新是最慢的操作。

这种策略下，缓存与数据库的一致性不强，对一致性高的系统不建议使用。

三、旁路缓存下的一致性问题分析

业务场景用的最多的就是 Cache-Aside (旁路缓存) 策略，在该策略下，客户端对数据的读取流程是先读取缓存，如果命中则返回；未命中，则从数据库读取并把数据写到缓存中，所以读操作不会导致缓存与数据库的不一致。

重点是写操作，数据库和缓存都需要修改，而两者就会存在一个先后顺序，可能会导致数据不再一致。 针对写，我们需要考虑两个问题：

1）先更新缓存还是更新数据库？

2）当数据发生变化时，选择修改缓存（update），还是删除缓存（delete）？

将这两个问题排列组合，会出现四种方案：

接下来的分析大家不必死记硬背，关键在于在推演的过程中大家只需要考虑以下两个场景会不会带来严重问题即可：

如果第一个失败了，第二个就不用执行了，直接在第一步返回 50x 等异常信息即可，不会出现不一致问题。

只有第一个成功，第二个失败才让人头痛，想要保证它们的原子性，就涉及到分布式事务的范畴了。

1、先更新缓存，再更新数据库

先更新缓存再更新数据库

如果先更新缓存成功，写数据库失败，就会导致缓存是最新数据，数据库是旧数据，那缓存就是脏数据了。

之后，其他查询立马请求进来的时候就会获取这个数据，而这个数据数据库中却不存在。

数据库都不存在的数据，缓存并返回客户端就毫无意义了。

2、先更新数据库，再更新缓存

1）更新缓存失败

这时候我们来推断下，假如这两个操作的原子性被破坏：第一步成功，第二步失败会导致什么问题？

会导致数据库是最新数据，缓存是旧数据，出现一致性问题。

该图我就不画了，与上一个图类似，对调下 Redis 和 MySQL 的位置即可。

2）高并发场景

谢霸歌经常 996，腰酸脖子疼，bug 越写越多，想去按摩推拿放提升下编程技巧。

疫情影响，单子来之不易，高端会所的技师都争先恐后想接这一单，高并发啊兄弟们。

在进店以后，前台会将顾客信息录入系统，执行 set xx的服务技师 = 待定的初始值表示目前无人接待保存到数据库和缓存中，之后再安排技师按摩服务。

高并发先更新数据库，再更新缓存

最后发现，数据库的值 = set 谢霸歌的服务技师 = 520，而缓存的值= set 谢霸歌的服务技师 = 98。

520 号技师在缓存中的最新数据被 98 号技师的旧数据覆盖了。

所以，在高并发的场景中，多线程同时写数据再写缓存，就会出现缓存是旧值，数据库是最新值的不一致情况。

如果第一步就失败，直接返回 50x 异常，并不会出现数据不一致。

3、先删缓存，再更新数据库

按照前面说的套路，假设第一个操作成功，第二个操作失败推断下会发生什么？高并发场景下又会发生什么？

1）第二步写数据库失败

假设现在有两个请求：写请求 A，读请求 B。

写请求 A 第一步先删除缓存成功，写数据到数据库失败，就会导致该次写数据丢失，数据库保存的是旧值。

接着另一个读请 B 求进来，发现缓存不存在，从数据库读取旧数据并写到缓存中。

2）高并发下的问题

这样子会出现缓存的是旧数据，在缓存过期之前无法读取到最数据。肖菜鸡本就被 98 号技师接单了，但是大堂经理却以为没人接待。

该方案 pass，因为第一步成功，第二步失败，会造成数据库是旧数据，缓存中没数据继续从数据库读取旧值写入缓存，造成数据不一致，还会多一次 cahche。

不论是异常情况还是高并发场景，会导致数据不一致。miss。

4、先更新数据库，再删缓存

经过前面的三个方案，全都被 pass 了，分析下最后的方案到底行不行。

按照套路，分别判断异常和高并发会造成什么问题。

该策略可以知道，在写数据库阶段失败的话就直返返回客户端异常，不需要执行缓存操作了。

所以第一步失败不会出现数据不一致的情况。

1）删缓存失败

重点在于第一步写最新数据到数据库成功，删除缓存失败怎么办？

可以把这两个操作放在一个事务中，当缓存删除失败，那就把写数据库回滚。

高并发场景下不合适，容易出现大事务，造成死锁问题。

如果不回滚，那就出现数据库是新数据，缓存还是旧数据，数据不一致了，咋办？

所以，我们要想办法让缓存删除成功，不然只能等到有效期失效那可不行。

使用重试机制。

比如重试三次，三次都失败则记录日志到数据库，使用分布式调度组件 xxl-job 等实现后续的处理。

在高并发的场景下，重试最好使用异步方式，比如发送消息到 mq 中间件，实现异步解耦。

亦或是利用 Canal 框架订阅 MySQL binlog 日志，监听对应的更新请求，执行删除对应缓存操作。

2）高并发场景

再来分析下高并发读写会有什么问题……

读请求可能出现少量读取旧数据的情况，但是很快旧数据就会被删除，之后的请求都能获取最新数据，问题不大。

还有一种比较极端的情况，缓存自动失效的时候又遇到了高并发读写的情况，假设这会有两个请求，一个线程 A 做查询操作，一个线程 B 做更新操作，那么会有如下情形产生：

出了不一致的情况的概率微乎其微，发生上述情况的必要条件是：

通常 MySQL 单机的 QPS 大概 5K 左右，而 TPS 大概 1k 左右，（ps：Tomcat 的 QPS 4K 左右，TPS = 1k 左右）。

数据库读操作是远快于写操作的（正是因为如此，才做读写分离），所以步骤（3）要比步骤（2）更快这个情景很难出现，同时还要配合缓存刚好失效。

所以，在用旁路缓存策略的时候，对于写操作推荐使用：先更新数据库，再删除缓存。

四、一致性解决方案有哪些

最后，针对 Cache-Aside (旁路缓存) 策略，写操作使用先更新数据库，再删除缓存的情况下，我们来分析下数据一致性解决方案都有哪些？

如果采用先删除缓存，再更新数据库如何避免出现脏数据？

采用延时双删策略。

这样子最多只会出现 500 毫秒的脏数据读取时间。关键是这个休眠时间怎么确定呢？

延迟时间的目的就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

所以我们需要自行评估项目的读数据业务逻辑的耗时，在读耗时的基础上加几百毫秒作为延迟时间即可。

缓存删除失败怎么办？比如延迟双删的第二次删除失败，那岂不是无法删除脏数据。

使用重试机制，保证删除缓存成功。

比如重试三次，三次都失败则记录日志到数据库并发送警告让人工介入。

在高并发的场景下，重试最好使用异步方式，比如发送消息到 mq 中间件，实现异步解耦。

第（5）步如果删除失败且未达到重试最大次数则将消息重新入队，直到删除成功，否则就记录到数据库，人工介入。

该方案有个缺点，就是对业务代码中造成侵入，于是就有了下一个方案，启动一个专门订阅 数据库 binlog 的服务读取需要删除的数据进行缓存删除操作。

总结

缓存策略的最佳实践是 Cache Aside Pattern。分别分为读缓存最佳实践和写缓存最佳实践。

读缓存最佳实践：先读缓存，命中则返回；未命中则查询数据库，再写到缓存中。

在以上最佳实践下，为了尽可能保证缓存与数据库的一致性，我们可以采用延迟双删。

防止删除失败，我们采用异步重试机制保证能正确删除，异步机制我们可以发送删除消息到 mq 消息中间件，或者利用 canal 订阅 MySQL binlog 日志监听写请求删除对应缓存。

那么，如果我非要保证绝对一致性怎么办，先给出结论：

没有办法做到绝对的一致性，这是由 CAP 理论决定的，缓存系统适用的场景就是非强一致性的场景，所以它属于 CAP 中的 AP。

所以，我们得委曲求全，可以去做到 BASE 理论中说的最终一致性。

其实一旦在方案中使用了缓存，那往往也就意味着我们放弃了数据的强一致性，但这也意味着我们的系统在性能上能够得到一些提升。

---

mysql数据库性能测试

我理解的是你希望了解mysql性能测试的方法：其实常用的一般：选取最适用的字段属性MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。 因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。 例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。 同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。 因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。 这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries)MySQL从4.1开始支持SQL的子查询。 这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。 例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。 但是，有些情况下，子查询可以被更有效率的连接（JOIN）.. 替代。 例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )如果使用连接（JOIN）.. 来完成这个查询工作，速度将会快很多。 尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：SELECT * FROM customerinfo LEFT JOIN salesinfoON =salesinfo. CustomerID WHERE IS NULL连接（JOIN）.. 之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。 3、使用联合(UNION)来代替手动创建的临时表MySQL 从 4.0 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。 在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。 使用 UNION 来创建查询的时候，我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。 下面的例子就演示了一个使用 UNION的查询。 SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM authorUNIONSELECT Name, Supplier FROM product4、事务尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。 更多的时候是需要用到一系列的语句来完成某种工作。 但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。 设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。 要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败。 换句话说，就是可以保持数据库中数据的一致性和完整性。 事物以BEGIN 关键字开始，COMMIT关键字结束。 在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。 BEGIN;INSERT INTO salesinfo SET CustomerID=14;UPDATE inventory SET Quantity=11WHERE item=book;COMMIT;事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。 5、锁定表尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。 由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。 如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。 其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。 下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。 LOCK TABLE inventory WRITESELECT Quantity FROM inventoryWHEREItem=book; inventory SET Quantity=11WHEREItem=book;UNLOCK TABLES这里，我们用一个 SELECT 语句取出初始数据，通过一些计算，用 UPDATE 语句将新值更新到表中。 包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前，不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。 6、使用外键锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。 这个时候我们就可以使用外键。 例如，外键可以保证每一条销售记录都指向某一个存在的客户。 在这里，外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。 CREATE TABLE customerinfo( CustomerID INT NOT NULL , PRIMARY KEY ( CustomerID )) TYPE = INNODB;CREATE TABLE salesinfo( SalesID INT NOT NULL, CustomerID INT NOT NULL, PRIMARY KEY(CustomerID, SalesID), FOREIGN KEY (CustomerID) REFERENCES customerinfo (CustomerID) ON DELETECASCADE) TYPE = INNODB;注意例子中的参数“ON DELETE CASCADE”。 该参数保证当 customerinfo 表中的一条客户记录被删除的时候，salesinfo 表中所有与该客户相关的记录也会被自动删除。 如果要在 MySQL 中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。 该类型不是 MySQL 表的默认类型。 定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。 如例中所示。 7、使用索引索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候，性能提高更为明显。 那该对哪些字段建立索引呢？一般说来，索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。 尽量不要对数据库中某个含有大量重复的值的字段建立索引。 对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况，例如customerinfo中的“province”.. 字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。 我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。 此外，MySQL从版本3.23.23开始支持全文索引和搜索。 全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。 对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。 但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。 8、优化的查询语句绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。 下面是应该注意的几个方面。 首先，最好是在相同类型的字段间进行比较的操作。 在MySQL 3.23版之前，这甚至是一个必须的条件。 例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。 其次，在建有索引的字段上尽量不要使用函数进行操作。 例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。 所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。 SELECT * FROM order WHERE YEAR(OrderDate)<2001;SELECT * FROM order WHERE OrderDate<2001-01-01;同样的情形也会发生在对数值型字段进行计算的时候：SELECT * FROM inventory WHERE Amount/7<24;SELECT * FROM inventory WHERE Amount<24*7;上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。 第三，在搜索字符型字段时，我们有时会使用 LIKE 关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。 例如下面的查询将会比较表中的每一条记录。 SELECT * FROM booksWHERE name like MySQL%但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：SELECT * FROM booksWHERE name>=MySQLand name

一个EXCEL文件才出现如下提示:"Ox3095fdc"指令引用的“Ox00000004"内存不能为"read".

1.在EXCEL中点击菜单文件>>打开>>选中这个文件>>按钮打开旁边的下拉箭头>>打开并修复，偿试一下2.看看其它修复工具比如 EasyRecovery或EXCELFIX能否再行修复Concept Data公司提供了一个专门用于修复Excel损坏文件的修复工具ExcelRecovery，能够对Excel 5.0/97/2000的文件进行恢复处理，大家可以先下载该软件的免费演示版试用，仅有674KB。 软件安装后，可以自动将Excel的修复程序加在Excel应用程序中，在“文件”菜单下多出一项“Recovery”选项，若有损坏的文件，可以用该选项进行修复。 >>>>使用方法是：>>>>1、打开Excel；>>>>2、单击“文件”菜单下的“Recover”选项，Excel Recovery对话框将打开；3、指定要修复的Excel文件，然后按[Recover]按钮；>>>>4、自动修复；>>>>5、另存为一个新的文件名，即可完成文件的修复工作。 >>>>注意：该演示版本只能修复普通文件，不能修复带Visual Basic代码、图表以及包含口令的Excel文件，如果需要修复这些文件，需要付米米进行注册。 >>>>我用过几次，基本上都能修复。 3.如果还是不行，可以使用记事本打开，然后将里面剩余数据整理出来再修复不了我也在实没办法了，以后多注意做备份，在操作工作表的时候不要强行退出，如保存工作表的时候

memcached和redis的区别

medis与Memcached的区别传统MySQL+ Memcached架构遇到的问题　实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：　需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 与MySQL数据库数据一致性问题。 数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。 4.跨机房cache同步问题。 众多NoSQL百花齐放，如何选择　最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题　1.少量数据存储，高速读写访问。 此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。 前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。 free，auto-sharding等。 比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。 面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。 Redis适用场景，如何正确的使用　前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：　1Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 2Redis支持数据的备份，即master-slave模式的数据备份。 3Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。 在Redis中，并不是所有的数据都一直存储在内存中的。 这是和Memcached相比一个最大的区别。 Redis只会缓存所有的 key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。 然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。 这种特性使得Redis可以 保持超过其机器本身内存大小的数据。 当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。 同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。 使用Redis特有内存模型前后的情况对比：　VM off: 300k keys, 4096 bytes values: 1.3G used　VM on:300k keys, 4096 bytes values: 73M used　VM off: 1 million keys, 256 bytes values: 430.12M used　VM on:1 million keys, 256 bytes values: 160.09M used　VM on:1 million keys, values as large as you want, still: 160.09M used当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。 在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。 这种策略在客户端的数量较小，进行 批量操作的时候比较合适。 但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。 所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。 如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。