分布式入门

转载至https://www.cnblogs.com/zhy-1992/p/9233789.html

二、背景说明

优点：高性能、高并发、高可用、安全性

例如像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。

下面我们来简单模拟一个架构演变过程。

​假如我们系统具备以下功能:
用户模块:用户注册和管理。
商品模块:商品展示和管理。
交易模块:创建交易及支付结算。

三、阶段一：单应用架构​

四、阶段二：应用服务器和数据库服务器分离（增加机器）

五、阶段三：应用服务器集群（访问量增加，增加应用服务器）

问题：

• 用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡)
• 用户如果每次访问到的服务器不一样，那么如何维护

  session，达到session共享的目的。

解决方案：

• 负载均衡又可以分为软负载和硬负载。软负载我们可以选择Nginx、Apache等，硬负载我们可以选择F5等。
• session共享问题我们可以通过配置tomcat的session共享解决。

六、阶段四：数据库压力变大，数据库读写分离（查询和增删改分离）

问题：

• 主从数据库之间的数据同步(可以使用 mysql 自带的 master-slave 方式实现主从复制 )

ps： 数据同步，如a->b转账，a转账100，-100，此时数据库挂掉，数据库锁机制应该回流给a资金

• 应用中根据业务进行对应数据源的选择( 采用第三方数据库中间件，例如 mycat )

七、升级阶段五：搜索引擎缓解读库的压力（数据库索引relate with搜索引擎）

八、升级阶段六：引入缓存（内存）机制缓解数据库的压力（内存的读写比硬盘快得多）

九、阶段七：数据库的水平/垂直拆分

垂直拆分:不同业务数据分库

水平拆分:业务数据量太大，同一个表分表

十、阶段八：应用的拆分

应用拆分：按照领域模型将我们的用户、商品、交易拆分成多个子系统。

问题：
这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。

解决方案：通过走服务化路线的方式来解决

问题：
服务拆分以后，各个服务之间如何进行远程通信呢?
解决方案：
通过 RPC 技术，比较典型的有:dubbo、webservice、hessian、http、RMI 等等