Web应用中的数据库集群与分布式系统一致性-优快云博客

本文探讨了大型Web应用中数据库系统的发展，从单机到集群，再到分布式系统，强调了数据库拆分、读写均衡和数据一致性的重要性。随着流量和数据量增长，数据库演变为多机多数据库，解决读写压力，并通过表拆分应对性能需求。随着性能瓶颈出现，引入Cache系统，面临数据同步和时效性挑战。在极端情况，可能需要开发特型数据系统，以保持数据的一致性并同步到其他系统。

Web 系统中的数据库系统

对于大型 Web 应用中，数据库系统必然会发展为数据库集群，差别只在于这个集群是手工维护，还是自动维护（开发数据库集群系统）。还有一些海量数据、海量访问的 Web 应用不仅仅只使用数据库作为唯一的数据存储模型，而是数据库系统、特型数据系统、 Cache 系统需要共同配合，这样的一个分布式系统如何保证数据的分布性和一致性。

1. 数据库集群解决什么问题？

2. 分布式系统中的分布、同步问题

假设有一个论坛系统，数据库中至少有 Forum/Thread/Post 表，设计如下

Forum

id	Int	Auto increase
name	Char(64)
creater
Create_time
…..

Thread

Id	Int	Auto increase
Forum	Int	Foreign key
Title	Char(64)
Creater
Create_time
…..

Post

id	Int	Auto increase
Forum	Int	Foreign key
Thread	Int	Foreign key
name	Char(64)
creater
Create_time
…..

假设随着产品流量增长、数据量的增长，数据库系统可能发生的变迁如下图：

最初为单机单数据库，再演化为多机多数据库（此时的数据库是同质的），再继续演化、数据库内部表的拆分（这里方法很多，比如 1. 数据库中不同表的拆分 2. 同一个表的拆分等等 3. 相同数据的不同冗余方式）。

在单机单数据库演化为多机多数据库，主要目的解决读写均衡问题，此时读请求多于写请求，采用一注多从模式，将读请求分发到从库，写请求分发到主库，主从之间进行同步。

进行表的拆分目的有， 1. 单表压力过大，比如 Forum 可以按照 Forum id 取模拆分等。 2. 业务需求导致某些表压力不均衡，比如： Thread 表、 Post 表压力都比较大，可以分布在不同的机器上。 3. 其他。

细心的读者获取会发现，至此是依据性能需求，调整数据库的拆分部署、表的拆分部署等等工作，如果我们有这样一个数据库集群软件，他能智能地根据应用的需求变化调整机器数量、调整数据库的部署，当然还应具备单点恢复、宕机冗余、灾难恢复、统一接入等等功能，其实这就是云存储（数据库的云存储模型）。坦言，目前接触的一些大型互联网公司， mysql 的集群系统还没有真正形成。

继续向前发展，数据库性能不够时，会产生 Cache 来承载数据库的性能瓶颈。此时存在这样问题：（这些问题暂时不讨论，在 Cache 部分讨论）

1. Cache 时效性。如何与数据库数据同步，过期数据等等。

2. Cache 粒度。最典型的讨论是 Cache 翻页失效。

3. 其他

继续向前发展，是否是所有的数据交给数据库存储就能搞定，当然不是。以论坛为例，假设 forum 中的 thread 列表按照最后回复时间排序，某 fourm 中的 thread 数量过亿，此时怎么处理？ 1. 历史存档区（这是产品设计上的处理方式）。技术上呢？拆表？因为该 forum 下的 thread 都需要参与排序，将 thread 列表拆成多个表来存储也不是很合适。此时，我想说明的问题是，在极端情况下，通用系统不能满足产品需求（数据库即是通用系统），必须有开发特型系统。百度贴吧、搜狐的论坛在 thread 列表处采用特殊开发的数据存储系统。问题来了，此时该如何同步数据？

方法一，以数据库为主，同步到特型系统

方法二，同步机制的系统

在大型 Web 应用中采用更多的是方法二，因为该同步机制自我开发，功能会更丰富和全面，可控性更强，后端数据系统仅仅承担数据的存储角色。方法一，主要依附于数据库的同步机制，可控性较差，数据库不仅承担数据的存储角色还承担了同步角色。自主开发同步机制系统时，也有一些开源软件可以借鉴。（其中定义 Group 概念，相同 Group 下的组件需要保持状态一致）。

到这儿，我们在讨论什么？其实我们在讨论分布式系统，我们通过分布式提高系统的承载量，同时又需要提供保证数据一致性的机制。