分布式系统总结

一、集群Cluster
1.无数据，高可用，访问量，LB 应用无状态集群，计算级集群（没有私有（局部）或少量私有数据，web中的session）
2.有数据 无中间proxy，靠客户端算法 配置
3.有数据 有中间proxy,中间proxy分发 haproxy,nginx,policy策略（整体或集群），ip，banace, cookie,最少
a.主从 访问量 读写 用户定义场景多
b.分区 数据分隔到多台机器，不可聚合
c.访问量和高可用 gossip 主从 选举主备 整体可用
d.双主 数据同时同步,少见
e.主备 整体数据同步，监控+操作（切换、调整） vip，sentinel，standby，keepalived，高可用

有数据的集群，无数据的集群
decouple

高可用，高可靠
高可用：服务器+网络 到岸 统计方式不一样 失效+修复+正常时间 不容易出问题（与我相关）
高可靠：服务器 离岸 正确性 容错器 边界 条件 不容易出错（内部）
测试

二，底层协议Protocol
cap c数据一致性（BASE 时实一致，最终一致，软状态） a 访问量大后系统的可用性(部有可用，场景可用) p 网络分区容忍性，局部失效 网络延迟，数据延迟，分布式必有特性
Paxos 2pc 3pc zookeeper
gossip 应用级别广播 数据一致，广播一点发声，gossip二次传播，流言蜚语，P2P的通信协议

ACID与BASE
AP without C

你编号高，我比你更高，反复如此，算法永远无法结束，这叫活锁，永远没有结果
死锁，互相占有对方关键资源

说起paxos，需要稍微提提二段提交。简单来说，二阶段提交就是1.一个节点询问其他节点，我是不是可以进行消息提交。2.如果收到所有人的同意，则告诉大家，开始提交吧。这个协议在实际中并不能很好的解决分布式中信息同步问题。例如只要有节点失效，就会发生得不到所有人同意的结果，在超时后，这一次提交失败，等一系列问题。但是paxos在对二段提交进行了优化后，得到了一个比较好的解决办法。
paxos协议引入了多数派，以及消息编号的概念。在1准备时，询问2/n+1的参与者，要求他们保证不会接受小于编号n的提交。
2.如果得到了2/n+1的回复，则可以开始告诉2/n+1的参与者进行消息的提交。
可以明显的看出，这就是对二段提交的一个优化版。就是这么一个比较巧妙的思想，解决了一些二阶段提交带来的问题。

===========================
三、中间件
redis :一级缓存，二缓存，缓存主动更新，被动更新，统一数据库操作入口（服务），适当
MQ: 异步，EDA, 状态机，可靠，解偶，消息暂停
JOB: 时间触发，执行
日志：客户端，服务端（收集，存储），搜索，界面
监控：计数
ORM: 数据访问
MSA：apigateway

事件：发送者，消息; sender eventArgs

===============================
其它的不重要：
1.IOC， automapper
2.WINDBG
3.CTI：邮件和短信，供应和消费
4.大数据 hbase, opentsdb
5.jenkins
6.fx
7.nuget
8.solr
9.zookeeper
11.加解密
12.数据字典
13.图片, FastDFS, ceph, sheepdog 存储
14.dashboard hchart echart
15.MongoDB
16.MemcacheD
17.报警：Alarm(报警器), alert（报警）, CTI(邮件，短信，IM)，通知+触发条件, （指标+值）+关系=》判定=》内容=>通讯（通知）
18. HApoxy, nginx, keepalived, lvs, zabbix, cacti,nagios

四、应用
1.应用级别可伸缩：分（水平，垂直，虚拟化，无状态, 异步），合（事务，数据集中），缓存
2.portal: SSO，采购商门户
3.企业支付网关Enterprise Payment Gateway
4.结算门户，运营门户
5.产品，订单服务，营销 查询，交易（下单），前后端分离，商务主体相分离（供应链，大环节，大角度，商务主体，商务参与者）
6.报告：次日，报表服务器，时实查询，报表，大数据分析

主体：在商务活动中，有一家权利和义务的个人和组织
客体：自己接触的但不属于自己的实体。指外界事物，是主体的认识对象和活动对象。