日期

0711

总结开始

1. 一致性HASH

啥是一致性HASH？

为了解决分布式缓存集群中，当集群服务器扩容时，数据访问不一致的问题。（为何不一致？传统的余数hash，加机器会导致除数变化，产生整个数据访问不一致，会导致缓存雪崩）

如何实现？

先建立一个2^32大的一个环，将服务器的节点的若干个虚拟节点的hash值放到环上，然后将要计算的key的值的hash值也放到环上，沿着环顺时针查找，离它最近的服务器的节点就是

2. 数据分片

啥是数据分片？

当数据量过大，超过单库单张表的存储能力或者写入能力时，将一张表拆分成若干片，写入到多个服务器，降低单个服务器上该表的存储能力和写入能力

分片的实现方式？

2.1 硬编码方式

应用层根据分区键来判断分片位置

2.2 映射表方式

在映射表中记录分区键与服务器的映射关系

2.3 分布式数据库中间件（常用的中间件是Mycat）



MyCat分布式数据库中间件的核心模块是SQL解析模块、SQL路由模块、结果集合并模块

2.3.1 SQL解析模块：将SQL脚本解析为语法树，取出分库键的数据

2.3.2 SQL路由模块：将分区键按路由规则判断（余数哈希），判断该键值的数据落在哪个库（注意，这里是哪个库而不是哪个服务器，对后续的增加新服务器时数据迁移动作有帮助）

2.3.3 结果合并模块：SQL查询的数据可能来自于在不同的库上，将多个库返回的数据合并成一个结果集

2.3.4 扩增服务器时，如何保证数据迁移后数据访问与原来一致？

目前mycat分片是采用的余数哈希的规则，当增加服务器节点时除数改变，如果要保持数据访问一致性，需要将原有分片中的数据进行大规模的迁移，复杂且风险大。

解决方案：采用预先分库的方案，事先将数据按需分成多个库，比如有三台主机预先分12个库，每台主机上存放4个库。当新增服务器节点时，只需要将部分库整体迁移到新的服务器，形成每台主机3个库的效果，对整体库进行迁移比将库中的部分数据迁移要简单的多。迁移完成后，将路由配置文件中库与主机的映射关系，切换到新服务器修改即可。



当数据迁移时，应用同时在访问数据库，此时不迁移到新库，同步的速度大于应用写入的速度，当数据迁移完成后，切换到新的服务器上。

3. CAP原理

C：Consistency 一致性，每次读取的数据应该是最近一次写入的数据或者错误，而不是过期的数据

A：Availability 可用性，每次请求都应该得到一个响应，而不是返回一个错误或者无响应，不过这个响应不要求是最近一次写入的

P：Partition tolerance 分区耐受性，即使因为网络原因部分服务器节点之间消息丢失或者网络延迟，系统依然是可以操作的。

如何理解CAP原理：

CAP中的P相关的问题（网络分区失效）是一定会发生的，所以P是一定要保证的，但是可用性和一致性是互斥的关系，是无法同时满足的。

当网络分区失效发生时，要么取消操作，保证一致性，但是系统就不可用了；要么继续写入数据，但是数据的一致性无法保证。

当网络分区失效（网络不可用时）发生时，如果选择了一致性，系统就可能返回一个错误码或者超时，系统不可用。如果选择了可用性，系统总是可以返回一个数据，但是不能保证数据是最新的。

CAP原理，准确的说法是，在分布式系统必须满足分区耐受性的前提下，可用性和一致性无法同时满足。



目前大部分分布式系统保证的是AP同时保证最终一致性，最终一致性一般有以下几种方案来解决一致性冲突：

最终一致写冲突：记录时间戳，当数据在不同节点间扩散时，按照时间先后顺序覆盖最新的结果。

客户端冲突解决：比如在不同的节点上操作购物车，可以采用合并的方法，数据扩散时将所有节点的数据合并在一起。

投票解决冲突（Cassandra）：写数据时，向所有节点写数据，等待多数节点写入成功。当读取数据时，以返回相同数据的节点数多的为准。

4. HBASE架构

总结结束