《⼤型⽹站系统与JAVA中间件实践学习笔记》-1
第⼀章：分布式系统介绍
  定义：分布式系统是⼀组分布在⽹络上通过消息传递进⾏协作的计算机组成系统。
分布式系统的意义
升级单机处理能⼒的性价⽐越来越低
单机处理器能⼒存在瓶颈
处于稳定性和可⽤性考虑
阿姆达尔定律：s(P)=1/((1-p)+p/N)
  其中P指的是程序中可并⾏的部分的程序在单核上执⾏的时间的占⽐，N表⽰处理器的个数（核⼼数）。S(N)是指程序在N个处理器相对单个处理器的提升速度⽐。
单进程多线程和多进程的区别
  线程是属于进程的，⼀个进程内的多个线程共享进程的内存空间；⽽多个进程之间的内存空间是相对独⽴的，因此多个进程间通过内存共享、交换数据的⽅式与多个线程间的⽅式就有所不同。多进程相对于单进程多线程的⽅式来说，资源控制更容易实现，此外多进程中单个进程出现问题不会造成整体不可⽤。
分布式系统的难点
1. 缺乏全局时钟
2. ⾯对故障的独⽴性。在分布式系统，整个系统的⼀部分有问题⽽其它部分正常是经常出现的情况，我们称之为故障的独⽴性。
3. 单点故障。在整个分布式系统中，如果某个⾓⾊或者功能只有单台机器在⽀撑，那个这个节点称为单点，发⽣的故障称为单点故障。
在分布式系统中要尽量避免出现单点。如果不能把单机实现变为集实现，那么⼀般还有两种选择：
给这个单点做好备份，能够在出现问题是进⾏恢复，并且尽量做到⾃动恢复，降低恢复所需要使⽤的时间。
降低单点故障的影响范围。
  4.事务的挑战。
第⼆章：⼤型⽹站及架构的演进过程
1.从⼀个单机交易⽹站说起
  所有的功能模块和数据在单台服务器上，通过各个模块之间通过JVM内部的⽅法调⽤来进⾏交互，⽽应⽤和数据库之间是通过JDBC进⾏访问的。
2.单机负载告警，数据库与应⽤分离
  随着访问量的增加，服务器负载持续升⾼，考虑将应⽤服务器和数据库服务器分离。
3.应⽤服务器负载告警，如何让应⽤服务器⾛向集
  应⽤服务器压⼒变⼤时，根据对应⽤服务器的监测结果，可以考虑将服务器从⼀台变为两台，增加服务器后急需解决如下连个问题：
1. ⽤户对于应⽤服务器的选择问题，可以通过在应⽤服务器前增加负载均衡设备来解决。
2. Session问题。
3.1引⼊负载均衡设备
  引⼊负载均衡设备后的架构
3.2解决应⽤服务器的Session问题
  HTTP协议本⽣是⽆状态协议，需要基于HTTP协议⽀持回话(Session State)状态机制。具体的实现⽅式为：在回话开始时，分配⼀个唯⼀的回话标识(SessionID)，通过Cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器会带上这个会话标识告诉服务器请求数据那个会话。在Web服务器上，各个会话有独⽴的存储，保存不同的回话信息。如果遇到禁⽤Cookie的情况，⼀般的做法就是把这个回话标识放到URL的参数中。
  如上图所⽰，如果第⼀次⽹站请求在左边的服务器，那么Session保存在左边的服务器上，如果不做处理，就不能保证每次请求都落在同⼀台服务器上，这就是Session问题。
Session Stickey
  保证同⼀个回话的请求都落在同意Web服务器上，称为Session Stickey。
  这种⽅案可以让同样的Session请求每次都发送到同⼀个服务器进⾏处理，⾮常利于对Session进⾏服务器端本地缓存。不过带来以下问题：
1. 如果服务器宕机或者重启，那个这台服务器上的回话数据会丢失。
2. 回话是应⽤层信息，那么负载均衡要将同⼀个回话请求都保存到同⼀个Web服务器上的话，就需要进⾏应⽤层负载均衡，这个开销⽐
第四层的交换要⼤。
3. 负载均衡器会变为⼀个有状态节点，要将会话到具体Web服务器的映射保存。和⽆状态的⼏点相⽐，内存消耗更⼤，容灾⽅⾯会更⿇
烦。
Session Replication
负载均衡器的作用  Session Replication在Web 服务器之间增加了会话数据同步机制，通过保证不同Web服务之间的Session数据的⼀致，来解决Session 问题。⼀般的应⽤容器都⽀持Session Replication。和Session Replication相⽐，它对负载均衡设备没有要求，但是其本⽣也存在⼀些缺点。
1. 同步Session数据造成了⽹络带宽的开销。
2. 每台服务器都要保存保存所有的Session数据，如果整个集的Session数很多，每台机器⽤户保存Session的数据占据内存严重。
Session 集中存储
  该⽅案的问题：
1. 读写Session数据引⼊了⽹络操作，这相对于本地数据读取来说，问题就在于存在时延和不稳定性。
2. 如果集中的Session服务器或者集有问题，会对应⽤产⽣严重影响。
Cookie Based
  该⽅案通过Cookie来传递Session数据，将Session数据存放在Cookie中，然后在Web服务器上从Cookie中⽣成对应的Session数据。相对于Session 集中存储，这个⽅案不会依赖⼀个外部存储系统，也就不存在从外部系统获取、写⼊Session数据的⽹络时延。
  该⽅案存在的不⾜：
1. Cookie长度的限制。
2. 安全性。
3. 带宽消耗。
4. 性能影响。每次Http请求和响应都带有Session数据，对于Web服务器来说，在同样的处理情况下，响应的结果会减少，⽀持的并发数
就越多。
4.数据库读压⼒变⼤，读写分离
采⽤数据库作为读库
  读写分离导致的问题：
1. 数据复制问题。
2. 数据源选择问题
  数据库系统⼀般都提供了数据复制功能，但是对于数据复制还需要考虑数据复制的时延问题。数据复制延迟会带来数据短期不⼀致问题。于此同时，对于写操作主要⾛主库，事务中的读也要⾛主库，也要考虑到备库相对于主库的延迟。
搜索引擎其实是⼀个读库
  搜索引擎要⼯作，⾸要的⼀点是需要根据被搜索的数据来构建索引。
  搜索集的使⽤⽅式和读库的使⽤⽅式是⼀样的。可以从两个维度对搜索系统构建索引的⽅式进⾏划分：⼀种是按照全量/增量划分，另⼀种是按照实时/⾮实时划分。搜索引擎的技术解决了站内搜索时某些场景下的读的问题，提供更好的查询效率。
加速数据读取的利器-缓存
数据缓存
  ⼤型系统中的数据缓存主要⽤于分担数据库的读的压⼒。⼀般在缓存中存放的是“热”数据⽽不是全部数据。应⽤访问缓存，如果缓存不存在，则从数据读出数据后放⼊缓存。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。