数据库服务为上层 Web 应用提供关系式或结构化的数据存储与查询支持

数据库服务为上层 Web 应用提供关系式或结构化的数据存储与查询支持

数据库服务为上层 Web 应用提供关系式或结构化的数据存储与查询支持。取决于具体用例，Web 应用可以使用数据库连接器之类的插件机制来提供对不同数据库服务的访问支持。在这种架构下，用户可以灵活地选择或变更最适合企业现阶段情况的不同数据库产品。

例如：用户可以在原型阶段使用 SQLite 之类的嵌入式引擎完成快速部署和功能验证；而在应用的初期阶段切换到廉价的 MySql 数据库解决方案；等到业务需求不断上升，数据库负载不断加重时再向 Clustrix、MongoDB、Cassandra、MySql Cluster、ORACLE 等更昂贵和复杂的解决方案进行迁移。

Memcached 服务作为一个完全基于内存和 <Key, Value> 对的分布式数据对象缓冲服务，拥有令人难以置信的查询效率以及一个优雅的，无需服务器间通信的大型分布式架构。

对于高负载 Web 应用来说，Memcached 常被用作一种重要的数据库访问加速服务，因此它不是一个必选组件。用户完全可以等到现实环境下的数据库服务出现了性能瓶颈时在部署它。

值得强调的是，虽然 memcached 并不是一个必选组件，但通过其在 YouTube、Wikipedia、http://Amazon.com、SourceForge、Facebook、Twitter 等大型 Web 应用上的多年部署可以证明：memcached 不但能够在高负载环境下长期稳定地工作，而且可以戏剧性地提升数据查询的整体效率。

当然，我们也应该注意到：以 memcached 为代表的分布式缓存系统，其本质上是一种以牺牲一致性为代价来提升平均访问效率的妥协方案——缓存服务为数据库中的部分记录增加了分布式副本。对于同一数据的多个分布式副本来说，除非使用 Paxos、Raft 等一致性算法，不然无法实现强一致性保证。

矛盾的是，memory cache 本身就是用来提升效率的，这使得为了它使用上述开销高昂的分布式强一致性算法变得非常不切实际：目前的分布式强一致性算法均要求每次访问请求（无论读写）都需要同时访问包括后台数据库主从节点在内的多数派副本——显然，这还不如干脆不使用缓存来的有效率。

另外，即使是 Paxos、Raft 之类的分布式一致性算法也只能在单个记录的级别上保证强一致。意即：即使应用了此类算法，也无法凭此提供事务级的强一致性保证。

除此之外，分布式缓存也增加了程序设计的复杂度（需要在访问数据库的同时尝试命中或更新缓存），并且还增加了较差情形下的访问延迟（如：未命中时的 RTT 等待延迟，以及节点下线、网络通信故障时的延迟等）。

与此同时，可以看到：从二十年前开始，各主流数据库产品其实均早已实现了成熟、高命中率的多层（磁盘块、数据页、结果集等）缓存机制。既然分布式缓存有如此多的缺陷，而数据库产品又自带了优秀的缓存机制，它为何又能够成为现代高负载 Web App 中的重要基石呢？

其根本原因在于：对于十年前的技术环境来说，当时十分缺乏横向扩展能力的 RDBMS（SQL）系统已成为了严重制约 Web App 等网络应用扩大规模的瓶颈。为此，以 Google BigTable、Facebook Cassandra、MongoDB 为代表的 NoSQL 数据库产品，以及以 memcached、redis 为代表的分布式缓存产品纷纷粉墨登场，并各自扮演了重要作用。

与 MySQL、ORACLE、DB2、MS SQL Server、PostgreSQL 等当时的 "传统" SQL数据库产品相比，无论 NoSQL 数据库还是分布式缓存产品，其本质上都是以牺牲前者的强一致性为代价，来换取更优的横向扩展能力。

应当看到，这种取舍是在当时技术条件下做出的无奈、痛苦的抉择，系统因此而变得复杂——在需要事务和强一致性保障，并且数据量较少的地方，使用无缓存层的传统 RDBMS；在一致性方面有一定妥协余地，并且读多写少的地方尽量使用分布式缓存来加速；在对一致性要求更低的大数据上使用 NoSQL；如果数据量较大，同时对一致性要求也较高，就只能尝试通过对 RDMBS 分库分表等方法来尽量解决，为此还要开发各种中间件来实现数据访问的请求分发和结果集聚合等复杂操作……各种情形不一而足，而它们的相互组合和交织则再次加剧了复杂性。

来源：服务器，转载请保留出处和链接！

本文链接：http://www.cau168.com/post/24.html