中间件--软件胶水,起到桥梁的作用
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长连接
怕远程存储,可以使用本地存储作为容灾
第八章
更新索引的方式:
定时从数据库中拉取,数据库记录中记录更变时间的字段,要加索引,明显延时。
通过数据变更及时通知搜索引擎,及时性好,系统压力大