您的位置:首页 > 运维架构 > 网站架构

大型网站系统与Java中间件读书笔记

2016-02-25 21:09 274 查看

读书笔记

第二章.大型网站及其架构演进过程

1.什么是大型网站——大访问量、海量数据

2.大型网站的架构演进

1)用java技术和单击来构建网站

2)一个单机的交易网站

3)单击负载告警,数据库与应用的读写分离

4)应用负载告警,应用走向集群

A.应用负载均衡

B.解决应用服务器变为集群后的session问题

session sticky / Session Replication / Session数据集中存储 / cookie Based

C.小结

5)数据读压力大,读写分离

A.采用数据库作为读库,引入读写源

B.搜索引擎其实也是一个读库——建索引、什么样的功能应该走索引

C.缓存——数据缓存、页面缓存

6)关系型数据库和分布式存储系统——KV存储系统,读写分离中的读“源”

7)读写分离后的数据库瓶颈

A.专库专用,数据垂直拆分—把交易、商品、用户的数据分开,配置多个数据源

B.垂直拆分后的单机遇到瓶颈,数据水平拆分;解决SQL路由的问题;大数据量后的分页

8)数据库问题后的新挑战

A.拆分应用

B.服务化路线

9)初识消息中间件

10)总结

第四章:服务框架

4.1 网站功能持续丰富后的困境与应付

4.2服务框架的设计与实现

1.应用与集中式走向分布式所遇到的问题

2.透过事例看服务框架原型

A.单机方式

B.实现远程服务调用的客户端

C.实现服务端

3.服务调用端的设计与实现

A.确定服务框架的使用方式

从代码的角度看如何使用服务框架

运行期服务框架与应用和容器的关系

B.服务调用者和服务提供者之间通信方式的选择

1)远程通信遇到的问题

2)采用透明代理与调用者、服务提供者直连的解决方案

C.基于接口、方法、参数的路由

D.多机房场景

E.服务调用端的流控处理

F.序列化与反序列化

G.网络通信——BIO、NIO、AIO

H.支持多种异步服务调用方式——4种(OneWay,Callback,Future,可靠异步)

I.使用Future方式对远程服务调用的优化——调用多个远程调用的情景

4.服务提供端的设计和实现

A.如何暴漏远程服务

B.服务端对请求处理的流程

C.执行不同服务的线程池隔离

D.服务提供端的流控处理

E.服务升级

4.3.实战中的优化

4.4 服务化的服务治理

4.5 服务框架与ESB的对比

4.6 总结

六、消息中间件

6.1消息中间件的价值

6.1.1消息中间件定义

6.1.2 消息中间件应用——解耦应用

1.通过服务调用让其他系统感知事件发送的方式

2.消息中间件解耦服务调用

1)解耦调用;

2)保证消息一定能够被处理的方式(数据库存储、原子性、work around的方式)

6.2 互联网时代的消息中间件

6.2.1 如何保证消息发送的一致性

1.消息发送的一致性定义

2.JMS能够保证消息一致性吗

1)几个要素

2)消息模型:Queue和Topic模型、XA接口和非XA接口(数据库与事务管理器的标准接口)

3)最终一致性模型:

正向流程*

补偿流程*

解决业务操作和发送消息的一致性方案:发送消息的正常流程和检查业务操作结果的反向流程结合

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

方法一:保证消息中间件高可用

方法二:建立业务表和消息表,通过事务操作来保证(两种方法:消息中间件直接操作消息操作表;业务应用来操作消息操作表)—缺陷:事务操作

方法三:业务应用本地存储一份消息结构,业务数据进行消息补偿

6.2.3 消息模型对消息接受的影响

1.JMS-Queue队列模型——PTP模型

2.JMS-Topic订阅模型——Pub/Sub模型

3.JMS客户端处理连接的处理和带来的限制

4.我们需要的消息队列模型

分级处理,级联 Queue和Topic模型;

多集群订阅者解决方案——先Queue后Topic

6.2.4 消息订阅者订阅消息的方式

1.非持久订阅——中间件一启动,订阅关系就建立,与中间件的状态有关

2.持久订阅

6.2.5 保证消息可靠性的方法

消息系统示意图

1.消息发送端的可靠性保证—有消息送达返回标志即可;

2.消息存储的可靠性保证

1).基于文件的消息存储;

2).数据库作为消息存储;—-消息表、投递表

3).双机内存的消息存储——存储结构、故障处理结构;

3.消息系统的扩容处理

1).消息中间件如何自身扩容

2).消息存储的扩容处理——通过服务器主动安排投递的方式绕开根据消息Id取消消息这个动作;

4.消息投递的可靠性保证

1).投递消息——消息丢失(吃掉异常,然后确认消息处理成功);

2).投递处理的优化

投递消息采用多线程处理;

不同的线程池实现不同的功能;

通过Batch操作来实现消息的更新、删除;

重复消息处理;

6.2.6 订阅者视角的消息重复产生和应对

1.消息重复产生的原因

1)已发消息,未收到回执—-消息Id唯一,幂等保证即可;

2)消息已接受,消息存储问题——分布式事务,保证消息接收,处理成功更新投递状态为一个事务,成本高,还是要求幂等操作;

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

确认消息的类型

6.2.7消息投递的其他属性支持

1.消息优先级;

2.消息处理顺序和分机订阅;

3.自定义熟悉;

4.局部顺序;

6.2.8 保证顺序的消息队列的设计

消息队列结构、接收端消息接收的回溯支持;

1.单机多队列的问题和优化;(物理队列的数量设置与磁盘数有关)

2.本地消息存储的可靠性——主备;

3.队列的扩容

6.2.9 Push和Pull方式的对比

第7章 软负载中心与集中配置管理

7.1 初识软负载中心

1.软负载中心的作用(聚合地址信息;生命周期感知)

7.2 软负载中心结构

聚合数据、订阅关系、连接数据

7.3 内容聚合功能的设计

保证数据正确性

高效聚合数据

1.并发下的数据正确性保证;2.数据更新、删除的顺序保证;3.大量数据同时插入、更新时的性能保证;

7.4 解决服务上下线的感知

1.通过客户端与服务端的连接感知

2.通过对于发布数据中提供的地址端口进行连接的检查

7.5 软负载中心的数据分发的特点和设计

1.数据分发与消息订阅的区别

2.提升数据分发性能需要注意的问题

数据压缩

全量与增量的选择

7.6 针对服务化的特性支持

1.软负载数据分组

2.提供自动感知以外的上下线开关

(优雅地停止应用;保持应用场景,用于排错)

3.维护管理路由规则

7.7 从单机到集群

1.数据统一管理方案;

2.数据对等管理方案;

3.数据分组且数据对等管理方案;

7.8 集中配置管理中心

1.客户端实现和容灾策略(长轮询、数据缓存、数据快照、文件格式)

2.服务端实现和容灾策略(更新db、定期检查数据)

3.数据库策略
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息