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

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长连接

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

第八章

更新索引的方式：

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

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