download:Java全栈工程师【已完结】
拆分扩容后存在的问题
随着业务的增长，系统变得越来越庞大, 依据系统功用拆分红独立而又互通的项目, 比方买卖系统、财务系统、消费流程系统、物流系统、网站系统等等,但是散布式构造会存在很多问题。关于这些问题每一个都值得深化讨论,这儿简单的提一下,后面再开篇幅。
数据共享问题
一切的效劳之间数据如何共享同步,这是一个需求思索的问题,微效劳架构中,数据不可能只要一份,没法防止机器损坏等缘由形成的数据丧失,多份数据之间如何同步?目前可供参考的处理思绪是树立数据中心、搭建数据库集群。
接口调用问题
不同的效劳器之间停止调用遵照远程调用协议RPC
JAVA RMI：Java远程办法调用，即Java RMI（Java Remote Method Invocation）是Java编程言语里，一种用于完成远程过程调用的应用程序编程接口。 它使客户机上运转的程序能够调用远程效劳器上的对象。
dubbo:提供了面向接口代理的高性能RPC调用
耐久化数据雪崩问题
数据库分库分表,参考:MySQL调优之分区表。
资源隔离,参考:亿级流量架构之资源隔离思绪与办法。
缓存设定数据耐久化战略:Redis耐久化之RDB和AOF。
高并提问题
缓存:诸如缓存击穿、穿透、雪崩等,参考Redis击穿、穿透、雪崩产生缘由以及处理思绪。
数据闭环:为了便于了解,举个例子,关于淘宝而言,有网页版、IOS版、安卓版、还有什么一淘等等,固然客户端不一样,但是展现的商品信息是相同的,也就是一件商品,无论是哪个端用的数据是一样的,需求一套计划来处理并发下依据相同数据在不同端停止不同展现的问题,这就叫数据闭环。
数据分歧性问题
这是一个难点,大意就是多个效劳器之间数据如何保证分歧性,同样的商品在不同客户端效劳端端价钱应该是一样的, 通常运用散布式锁。
数据库扩容:集群
先简单说一下散布式与集群的区别,这两个词儿经常一同呈现,但是意义却有所不同,散布式会缩短单个任务的执行时间来提升工作效率，而集群强调的是进步单位时间内执行操作数的增加来进步效率。更简单的来说，散布式是将步骤分到每台电脑上，不思索依赖关系，集群计划是指几个任务同时在处置。
单一数据库存储难以满足业务需求时,采取集群的方式,将数据存储在不同的效劳器,这能够是主主或者主从,主从中主担任写,从担任读,将与数据库有关的压力停止合成到多台机器上。
散布式ID
在复杂散布式系统中，常常需求对大量的数据和音讯停止独一标识。很容易想到的是应用自增,但是自增有很多问题，例如ID有太强的规律,可能会被歹意查询搜集,面对数据日渐增长，对数据分库分表后需求有一个独一ID来标识一条数据或音讯，这样数据库的自增ID显然不能满足需求；特别一点的如商品、订单、用户也都需求有独一ID做标识。此时一个可以生成全局独一ID的系统是十分必要的。概括下来，那业务系统对ID号的请求有哪些呢？
散布式ID请求
面对散布式ID,需求满足下面的请求:
全局独一性：不能呈现反复的ID号，既然是独一标识，这是最根本的请求。
趋向递增：在MySQL InnoDB引擎中运用的是汇集索引，由于多数RDBMS运用B-tree的数据构造来存储索引数据，在主键的选择上面我们应该尽量运用有序的主键保证写入性能。
单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量音讯、排序等特殊需求。
信息安全：假如ID是连续的，歹意用户的扒取工作就十分容易做了，直接依照次第下载指定URL即可；假如是订单号就更风险了，竞对能够直接晓得我们一天的单量。所以在一些应用场景下，会需求ID无规则、不规则。
上述123对应三类不同的场景，但是3和4的需求是互斥的，也就是无法运用同一个计划满足。除了对ID号码本身的请求，业务还对ID号生成系统的可用性请求极高，想象一下，假如ID生成系统瘫痪，整个与数据有关的动作都无法执行，会带来一场灾难。由此总结下一个ID生成系统最少应该做到如下几点：
均匀延迟和TP999延迟都要尽可能低；
可用性5个9(这是美团的请求,有些企业例如阿里请求6个9)；
高QPS。
散布式ID生成战略
目前业界常用的ID生成战略有很多,例如UUID、雪花生成算法、Redis、Zookeeper等,这儿只简单讲讲UUID以及Snowflake，后面要开篇详谈。
UUID生成算法
UUID(Universally Unique Identifier)的规范型式包含32个16进制数字，以连字号分为五段，方式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID标准 A Universally Unique IDentifier (UUID) URN Namespace。
优点：
性能十分高：本地生成，没有网络耗费。
缺陷：
不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
信息不平安：基于MAC地址生成UUID的算法可能会形成MAC地址泄露，这个破绽曾被用于寻觅梅丽莎病毒的制造者位置。
ID作为主键时在特定的环境会存在一些问题，比方做DB主键的场景下，UUID就十分不适用：
① MySQL官方有明白的倡议主键要尽量越短越好[4]，36个字符长度的UUID不契合请求。
All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.
② 对MySQL索引不利：假如作为数据库主键，在InnoDB引擎下，UUID的无序性可能会惹起数据位置频繁变 动，严重影响性能。