<大型网站系统与Java中间件实践>读书笔记

DB

 

垂直分拆：

1.ACID原则

2.join查询

3.外键约束

水平分拆：

1.ACID原则

2.join查询

3.外键约束

4.自增唯一ID

5.跨库查询

 

分布式：

XA

AP/RM/TM 

 

AP->tx->TM

AP->XA Native API->RM

TM<--XA-->RM

 

两阶段提交

 

 

paxos协议-->ZooKeeper

集群内数据一致性的算法：Quorum、vector clock

 

多机sequence

1.唯一性

2.连续性

 

UUID

ID生成器

1.一个生成

2.规则生成器在各个服务器

week:

1.性能

2.稳定性

3.存储问题

 

跨库Join

1.业务多次查询

2.数据冗余

3.借助外部系统（引擎）

 

跨库查询

1.按特点分库分表

2.合并-->排序，函数处理，求均值，非排序分页，排序分页

 

数据库访问层

1.api方式

2.JDBC方式

3.ORM/类ORM方式

 

SQL规则处理

1.固定哈希算法

2.一致性哈希算法

3.虚拟节点对一致性哈希算法的改进

4.映射表与规则自定义计算方式

 

数据源连接

1.DataSource

2.groupDataSource

3.AtomDataSource

 

数据库访问实现方式

1.jar

2.proxy

 

读写分离的挑战与应对

场景

1.数据结构相同，多从库对应一主库

2.主/备库分库方式不同的数据复制

3.引入数据变更平台（Extractors，Applier,Pipleline）

 

数据平滑迁移

1.增量日志

2.复制数据到新库，并有新数据更新进来

3.全量迁移结束后，增量日志的数据也进行迁移

4.数据比对，记录差异

5.停止源数据对要迁移走的数据的写操作，后进行增量日志的处理，新库数据是新的

6.更新路由规则，所以新数据的读或写就到了新库

 

 

消息中间件

 

消息发送的一致性

1.分布式事务。-->XA协议

2.入库回调

 

消息中间件与使用者的强依赖问题

1.提升中间件系统的可靠性

2.消息存储位置与方式

 

限制

1.需要确定要发送的消息内容

2.需要实现对业务的检查

 

消息模型

1.Queue

2.Topic

 

集群

1.先Topic

2.消息中转

3.再Queue

 

订阅消息的方式

1.持久订阅

2.非持久订阅

 

保证消息可靠性的做法

1.持久订阅

2.消息存储

 

消息发送端可靠性的保证

回调检查

 

消息存储的可靠性保证

1.基于文件的消息存储-->查询，文件的空洞

2.数据库存储

3.双机存储

 

消息系统的扩容

1.中间件的扩容

2.存储的扩容-->1.不保证消息顺序2.不支持主动获取消息

 

消息投递的可靠性

消息投递的可靠性

投递处理的优化

1.线程池投递，结果进内存，再进行批量操作。

2.单机多订阅者共享链接

3.消息只发送一次，然后传到单机的多订阅都是生成多个实例处理。

 

订阅者角度的消息重复

原因

一.消息发送端发送重复

1.消息中间件收到消息存储成功后，中间件出现问题，导致应用端没有收到消息发送成功的返回，而进行重试

2.消息中间件负载高响应慢，返回结果超时

3.返回出现网络问题

二.消息中间件发送重复

1.接收者接收成功，处理完毕后应用出问题，消息中间件没有收到处理结果

2.接收者接收成功，处理完毕后网络出问题，消息中间件没有收到处理结果

3.接收者接收成功，处理时间长超时，消息中间件没有收到处理结果

4.中间件发送成功后，中间件出问题，没收到回复

5.中间件收到结果，但消息存储出问题，没更新投递状态。

 

处理方式

1.分布式事务处理-->比较复杂，成本也高

2.消息接收端做幂等操作-->接收端应用带来限制与门槛

 

JMS的消息确认方式与消息重复的关系

1.AUTO_ACKNOWLEDGE-->客户端自动确认，但可能消息还没得及处理或尚未处理完成。

2.CLIENT_ACKNOWLEDGE-->客户端自己确认，需主动调用Message接口的ackownledge()方法确认。

3.DUPS_OK_ACKNOWLEDGE-->消息接收方处理完成后进行确认。

 

接收者会出现两种情

1.at least once(至少一次)

1.at most once(至多一次)

 

消息传递的其他属性

1.优先级

2.订阅者消息处理顺序和分级订阅

3.自定义属性

4.局部顺序

 

                            push                   pull

1.数据传输状态            保存在服务端         保存在消费端

2.传输失败，重试   服务端维护传输状态，需重试  不需要

3.数据传输实时性     非常实时              短轮询依赖pull间隔时间，长轮询与push一致

4.流控机制      服务端需要订阅者的消费能力做流控  消费者可以根据自身的消费能力决定是否去pull消息