大型网站系统与Java中间件实践

中间件--软件胶水，起到桥梁的作用

 

volatile

读：不会有线程的本地副本，只会从主存读取

写：只有一份主存的数据

synchronized

读：保证本地副本与主存的同步

写：把当前线程修改的变量的本地副本同步给主存，从主存读取数据

 

wait一般写在循环中，判断相关状态是否达到预期，防止虚假唤醒

 

CountDownLatch

执行完countDown直接返回

不能循环使用

CyclicBarrier

调用await会阻塞等待

可以循环使用

 

semaphore

多用于控制并发量

 

网络编程

一个重要的内容就是协议的制定

 

网站的演进

应用的拆分、服务的拆分、数据的拆分、应用解耦

引入服务框架、数据层、消息中间件

 

服务框架要解决的问题

接口调用                   服务调用

路由                            实例定位

编码                            解码

通信         <-------->通信

 

 

每个机房的网段是不一样的

 

 

流量控制

前端                   动静分离、页面尽量静态化，用CDN扛、浏览器缓存、加入验证问题

Nginx        静态化、缓存、倒计时、限制访问频率、指定IP

jetty

kv

db              消除行锁

 

NIO客户端，调用方式：oneway、同步、callback、future

IO线程Dubbo默认使用单一长连接

耗时的操作例如：callback、反序列化可以转移到别的线程去做

 

 

调用服务在工作线程

 

 

根据一定的路由规则把请求发送到特定机器，然后做单机控制，避免分布式锁

 

 

服务治理

服务查看：质量、容量、依赖、分布、统计、

                  

服务管理：上下线、路由、限流降级、group、线程池管理、授权

 

 

 

第5章

降低DB压力：缓存、搜索引擎、垂直拆分、水平拆分

 

 

 

预写式日志

 

两阶段提交：参与者将操作成败通知协调者，协调者根据所有参与者的反馈，决定各个参与者是要提交还是中止

        

 

三阶段提交

都无法避免数据一致问题，在分布式数据库中，如果期望达到数据的强一致性，那么服务基本没有可用性可言，这也是为什么许多分布式数据库提供了跨库事务，但也只是个摆设的原因，在实际应用中我们更多追求的是数据的弱一致性或最终一致性，为了强一致性而丢弃可用性是不可取的。

 

Paxos前提是不存在拜占庭将军问题，可信的通信环境，消息准确，没被篡改。少数服从多数，设置一个Leader，如果出问题就重新选一个。

 

避免使用分布式事务，要用的话就保证最终一致，不要强一致。通过补偿机制不断重试，而不是回滚。

Paxos是不错的选择

 

CAP

         一致性：所有节点在同一时间读到同样的数据

         可用性：系统要有响应

         分区容忍性：部分节点出现问题，系统仍能继续工作

 

 

第6章

 

 

消息中间件不是强依赖，业务操作和写入消息作为一个本地事务

第七章

         采用http协议而不是私有协议可以更方便支持多种语言，比如用HTTP长轮询而不是Socket长连接

 

         怕远程存储，可以使用本地存储作为容灾

 

 

第八章

         更新索引的方式：

                   定时从数据库中拉取，数据库记录中记录更变时间的字段，要加索引，明显延时。

                   通过数据变更及时通知搜索引擎，及时性好，系统压力大