标签：点击 优点 超过 系统 jpg 并且 分布 受限 消息队列
最近在思考数据库以及缓存的问题，发现这些知识点其实是有一点关联的，于是这篇文章通过一个连环提问的方式将这些知识点串联起来。
答：因为 MySQL 等关系型数据库无法承受巨大的数据库访问量。
因为 MySQL 使用文件去存储数据，这就意味着它的查询和写入速度受限于硬盘的速度。虽然 MySQL 也使用了内存缓存一部分数据，但这只能减少一部分的查询请求，如果查询请求数变多，同样会到达硬盘的 IO 瓶颈。
另一方面，关系型数据库为了实现数据的强一致性，在每次写入数据的时候会对相关的数据进行加锁操作，这样就导致在某个时刻，相关的数据只能有一个线程在操作，这样也从某种程度上限制了 MySQL 的读写性能。
如果此时查询缓存并没有相关数据，那么还会有一部分 IO 等待的事件，从而导致加锁时间变长。
而 Redis、Memcached 之所以能够承受得住 MySQL 无法承受的海量查询，很大程度上是因为他们将所有数据都存在了内存中，所以它们并不需要进行 IO 等待，直接可以从内存中查询数据并返回。
而内存的读取效率则是硬盘的 40 倍左右，存储介质的巨大区别导致了他们的应用特性。
答：这就要说到这两种缓存的发展历史了。一开始是 2003 年发布的，一开始是为了解决数据库的读写瓶颈问题，于是将一些热点数据存储在内存中，从而有了 Memcached。
但经过几年的使用，人们发现 Memcached 存在一些问题，例如 Memcached 只支持 Key - Value 的字符串数据存储，Memcached 无法持久化数据，一旦重启服务器数据便丢失了。
出于这些原因，2009 年一些工程师在 Memcached 的基础之上打造了 Redis 框架，它与 Memcached 相比，支持更多的数据类型存储，例如：String, List, Set, SortedSet, Hash 等。此外还支持将存储在内存中的数据持久化到文件中，从而实现数据持久化。
另外 Redis 支持更大的数据存储，key-value 的存储大小可达 512M，而 Memcached 的 key 大小只有 512KB，而 value 则只有 1 M 大小。
另外它还支持许多的原子操作。因为 Redis 与 Memcached 相比有上述的优点，所以现在越来越多的人开始使用 Redis 作为缓存框架。
答：首先，无论 Redis 还是 Memcached，它们都是一个 NoSQL 数据库，并且都将所有数据存在内存中。现在确实有些公司还是使用 Memcached 框架作为缓存，Memcached 在某些方面确实比 Redis 好一些，虽然这些优势非常小。
例如 Memcached 在处理小数据量静态数据的速度会非常快，但是一旦数据量变大或者数据变动频繁，那 Memcached 的处理速度就会急剧下降。
另外一个 Memcached 的优势是 Memcached 是多线程的，所以如果你想提高 Memcached的性能，你可以直接给它换一个性能更加强劲的 CPU 就可以。
但是对于 Redis 而言，因为 Redis 是单线程的，所以如果你想提升 Redis 的处理能力，那么你只能多部署一台 Redis 服务器，这比起 Memcached 来说比较麻烦。
总结来说，Memcached 比起 Redis 来说，只有小数据量存储以及横向拓展这两个方面能勉强说得上「优势」，但其实 Redis 也能做得同样好，甚至超过它，只不过是需要花多点学习成本而已。
所以，如果你之前已经非常了解 Memcached 了，花了很多时间学习 Memcached 的知识，那么你可以选择 Memcached。
否则选择 Redis 是一个更好的选择，因为所有 Memcached 能做的，Redis 也能做，而且 Redis 能做到更多 Memcached 无法做到的事情。
答：作为缓存可能是 Redis 最广为人知的作用吧，但 Redis 除了作为缓存，还能作为消息队列解决方案、分布式锁等。
答：MongoDb 的出现与 Redis 的出现类似，都是用来解决 MySQL 无法实现海量访问而存在的。但 Redis 仅仅是一个 key-value 的缓存系统，其几乎没有任何数据库特性，在那些许多进行查询的场景中，redis 无法胜任。
在这个时候 MongoDb 凭借其出色和丰富的查询功能脱颖而出。
另外 MongoDb 也能存储比 MySQL 更加大量的数据。MongoDb 适合那种数据结构经常变化，数据之间没有联系，这种场景适合用 MongoDb，例如多重嵌套的留言回复。
标签：点击 优点 超过 系统 jpg 并且 分布 受限 消息队列
原文地址：https://www.cnblogs.com/chanshuyi/p/the_history_of_database_03.html
