分布式、高性能和高可用解决方案（分布式）.pdfVIP

分布式、⾼性能和⾼可⽤解决⽅案（分布式） 1分布式 分布式系统会把⼀个应⽤系统拆分为可独⽴部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作。切记，分布式⼀定是存 在⽹络分区的。 2使⽤分布式需要解决哪些问题？ 1）分布式 ID 2）rpc通信 3）分布式事务 4）分布式锁 5）分布式协调 下⾯我们逐⼀提供解决⽅法： 3分布式ID ⼀个最基本的分布式 ID 需要满⾜下⾯这些要求： 全局唯⼀ ：ID 的全局唯⼀性肯定是⾸先要满⾜的！ ⾼性能 ： 分布式 ID 的⽣成速度要快，对本地资源消耗要⼩。 ⾼可⽤ ：⽣成分布式ID 的服务要保证可⽤性⽆限接近于 100%。 ⽅便易⽤ ：拿来即⽤，使⽤⽅便，快速接⼊！ 除了这些之外，⼀个⽐较好的分布式 ID 还应保证： 安全 ：ID 中不包含敏感信息。 有序递增 ：如果要把 ID 存放在数据库的话，ID 的有序性可以提升数据库写⼊速度。并且，很多时候， 我们还很有可能会直接通过 ID 来进⾏排序。 有具体的业务含义 ：⽣成的 ID 如果能有具体的业务含义，可以让定位问题以及开发更透明化（通过 ID 就能确定是哪个业务）。 独⽴部署：也就是分布式系统单独有⼀个发号器服务，专门⽤来⽣成分布式 ID。这样就⽣成 ID的服务可以和业务相关的服务解耦。不 过，这样同样带来了⽹络调⽤消耗增加的问题。 总的来说，如果需要⽤到分布式 ID的场景⽐较多的话，独⽴部署的发号器服务还是很 有必要的。 3.1 UUID UUID 可以保证唯⼀性，因为其⽣成规则包括 MAC 地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，计算机基 于这些规则⽣成的 UUID 是肯定不会重复的。 UUID 的优缺点 : 优点 ：⽣成速度⽐较快、简单易⽤ 缺点 ： 存储消耗空间⼤（32 个字符串，128 位） 、 不安全（基于 MAC 地址⽣成 UUID 的算法会造成 MAC 地址泄露)、⽆序（⾮⾃ 增）、没有具体业务含义、需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产⽣重复 ID）。 3.2 Snowflake(雪花算法) Snowflake 是 Twitter 开源的分布式 ID ⽣成算法。Snowflake 由 64 bit 的⼆进制数字组成，这 64bit 的⼆进制被分成了⼏部分，每⼀部 分存储的数据都有特定的含义： 有很多基于 Snowflake 算法的开源实现⽐如美团 的 Leaf、百度的UidGenerator，并且这些开源实现对原有的 Snowflake 算法进⾏了优 化。 Snowflake 算法的优缺点 ： 优点 ：⽣成速度⽐较快、⽣成的 ID 有序递增、⽐较灵活（可以对 Snowflake 算法进⾏简单的改造⽐如加⼊业务 ID） 缺点 ： 需要解决重复 ID 问题（依赖时间，当机器时间不对的情况下，可能导致会产⽣重复 ID）。 3.3 数据库号段模式 将ID存在在内存⾥⾯，需要⽤到的时候，直接从内存⾥⾯拿。数据库的号段模式也是⽬前⽐较主流的⼀种分布式 ID ⽣成⽅式。像滴滴开源 的Tinyid (opens new window) 就是基于这种⽅式来做的。 不过，TinyId 使⽤了双号段缓存、增加多 db ⽀持等⽅式来进⼀步优化。 current_max_id 字段和step字段主要⽤于获取批量 ID，获取的批量 id 为： current_max_id ~ current_max_id+step。version 字段主 要⽤于解决并发问题（乐观锁）,biz_type 主要⽤于表⽰业余类型。 数据库号段模式的优缺点: 优点 ：ID 有序递增、存储消耗空间⼩ 缺点 ：存在数据库单点问题（可以使⽤数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（⽐如根据订单 ID 的递增 规律就能推算出每天的订单量，商业机密啊！） 3 RPC通信 3.1 什么是 RPC？ RPC（Remote Procedure Call）—远程过程调⽤，它是⼀种通过⽹络从远程计算机程序上请求服务，⽽不需要了解底层⽹络技术的 议。⽐如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调⽤服务 B 中的某个⽅法该怎么办呢？使⽤ HTTP请求 当 然可以，但是可能会⽐较慢⽽且⼀些优化做的并不好。 RPC 的出现就是为了解决这个问题。 3.2 RPC原理是什么 服务消费端（client）以本地调⽤的⽅式调⽤远程服务； 客户端 Stub（client