分布式前世今生

诞生

访问量大（高并发）

比如最初的系统使用用户只有100，系统功能太好用了，吸引了大量的新用户，现在用户10W。

响应速度慢（性能）

之前业务简单，一个 select * from xxx, 现在要加上各种where和group by ，order by,查询时间从0.1秒变成了10秒。用户说不好用了。

功能扩展（可扩展性）

之前只卖书，现在人们用到的东西我都想卖！我就是想正确！

数据量大了（高可靠）

时间能带走一切，也会带来一些东西，比如说：麻烦！

服务崩溃了（高可用）

服务器：之前我一个人养10个人，现在让我养10W人，老板还不加工资，累死机器了，干了一年了，放个年假吧。

简单总结下：用户越来越懒了！

改进

不要问我为什么改进，反正所有的优秀都是逼出来的！

背景
 1.摩尔理论：价格不变时，每隔18个月，计算机的性能会提升一倍！
 2.阿姆达尔定律：S(N)=1/[(1-P)+P/N]
 2.MapReduce思想：把大任务分解成一堆小任务，一个人处理一个小任务，最后把各自的结果整合在一起。
       中国人古语：分而治之！

高并发问题解决方案

并发编程：一个线程忙不过来就多派几个线程！

一台机器干不了那就派多台机器来同时干！

性能瓶颈问题解决方案

引入缓存，减少DB的压力

扩展问题解决方案

程序员：又加功能，这个项目都是代码了？。

老板：再起一个项目！

客户：新项目？我还要一个注册账号，好烦哦！

架构：这个问题我能解决！

项目之间使用网络通信，同步相关的信息！

高可靠问题解决方案

增加一个备份吧（所有数据的高可靠都是通过冗余保证）

高可用问题解决方案

机器太累了，那就多雇佣几个机器，实行任务划分，减轻压力，同时还符合高内聚。

新问题

高并发新问题

线程执行某个任务的时候发现要使用的资源正在被使用，有时候这个任务已经被其他线程处理过了，现在需要一个管理者，来分配调度和协调

RPC:zookeeper，dubbo等

缓存新问题

需要缓存的数据量太大了，缓存不够用。

NoSQL:Redis等

扩展新问题

项目太多了，如何管理和控制，协调？

微服务理念诞生，服务注册，治理中心诞生！

高可靠新问题

数据如何同步备份？

各种MQ

数据不一致问题如何处理？

CAP理论

高可用新问题

机器总是发生各种各样的故障，如何处理？主备已经不时用了

服务集群，各种各样的，CAP中做取舍，被舍弃的也要尽可能去“亡羊补牢”。

总结

数据备份的可靠性

负载均衡--服务集群

高可用--服务集群

拆分成微服务

NoSQL 提速

没有百分之百完美的解决方案？
 只有适合业务场景的解决方案，没有绝地完美的解决方案！