前言
之前，我们了解了很多分布式系统的理论，也去分析了常见的分布式系统的设计策略。那么有了这些的铺垫，我们今天，来聊一下，常见的一些分布式系统设计的实践。周末让大家，过了个儿童节，颓废的生活不能有，学习走起！
我们主要讨论几个通用性问题：
- 全局ID生成
- 哈希取模分配
- 路由表
- 一致性哈希
- 数据拆分
全局ID生成
我之前单独写了一篇文章，来介绍分布式系统环境中，系统唯一ID生成，有需要的，大家可以翻一下以前的文章。
首先呢，为何需要全局ID。在分布式系统环境中，由于使用了集群以及分布式应用形式，另外，数据库也存在着水平、垂直切分情况，必然需要有全局的ID，保证一致性。也满足CAP数据一致性要求。
分布式系统环境之前，单机时代，ID生成，往往通过以下几种方式：
Mysql 通过维护一张ID表
Oracle通过序列去生成ID
分布式系统环境中，数据库访问是高成本的操作，那么如何才能合理可用是大家需要了解的。
- UUID
UUID有以下几部分构成：
1） 当前日期和时间
2） 时钟序列
3） 全局唯一的IEEE机器识别号，如果有网卡，会从MAC地址获得，如果没有，则会以其他方式获得，感兴趣的同学，可以自己研究下
优点：API简单，易用
UUID.randomKey().toString()
缺点：占用空间大，可读性不强，字符串无法定制
2.ID 生成表模式
目前一般来说，对于业务量不高的系统，达不到分库分表的需求的，一般主键ID都是通过Mysql的自增ID生成。
CREATE TABLE litigation_case_info ( id bigint(0) NOT NULL AUTO_INCREMENT COMMENT '主键id', caseId varchar(30) NOT NULL COMMENT '案件申请唯一标识', courtCode varchar(30) NULL COMMENT '法院代码', courtName varchar(50) NULL COMMENT '法院名称', PRIMARY KEY (id) ) COMMENT = '诉讼险案件基本信息表';
- 从高可用角度考虑，需要调整自增初始值和步长，来让多台机器同时可以生成唯一的ID
优点：简单，易用
缺点：依赖mysql - Twitter 的 SnowFlake
github介绍，Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.目前初始版本已被内部废弃使用，等待最新版本的开源。但是我们仍然可以学习，这么优秀的实现
地址：https://github.com/twitter-archive/snowflake
Snowflake生成64位的ID，包括：
1） 41位的时间序列
2） 10位的机器标识
3） 12位的计数顺序号
优点：高性能、低延迟、独立应用，时间有序
缺点：需要独立开发部署 - 结合缓存方案
采用缓存，提前缓存ID方式，高性能、低延迟，但是会造成，ID不连贯。
哈希取模分配
哈希是最常见的数据分布形式。实现方式是通过可以描述记录的业务id或者key，通过hash函数计算取余。余数则作为处理该数据的服务器索引编号
只需要通过计算，就可以映射数据和处理节点关系，问题在于，ID容易出现分布不均等情况
一致性哈希
一致性哈希算法，是一种分布式哈希(DHT)算法，主要解决了分布式哈希的单调性和分散性问题。
单调性，指的要对已经存在的内容能够正常映射，避免在节点增减过程中，无法命中，类似于上文说的哈希取模分配，如果几点不断增加，计算方式就会失去平衡。分散性，指的就是解决哈希取模分配的不平衡问题、
实现方式如下：
按照hash方法，将对应的key放入一个2^32空间内，首尾相连，形成一个环。
优点：可以任意动态添加、删除节点
路由表模式
路由表，是配置好一张表，按照权重，选择对应的存储路径。适合场景，有明确的路由目的与指向，比如抽奖后台。
对于抽奖后台的实现，可以采用路由表，按照抽奖权重，数据拆分，路由存储。
优点：简单明了
缺点：数据中央集权，存在单点风险。
数据拆分
如果能够找到一个合理的方式，去采用路由表模式，也会很好的解决数据问题，那么就出现了，数据拆分的形式。
举例说明：
Cobar，是alibaba开源的分布式数据库中间件，可以按照配置的路由规则，完成数据拆分。可以自定义拆分路由规则。具体内容，后续，我们会写代码详细说明
Sharding-jdbc，当当开源的分布式数据库中间件，也是完成对于数据的拆分、切片，具体内容，后续，我们会写代码详细说明
Mycat，分布式数据库中间件实现了分库分表，具体内容，后续，我们会写代码详细说明
