分布式笔记
系统的发展：架构的演进。遇到问题，解决问题
单点-->集群-->分布式
节点、副本（备份）、中间件（缓存中间件、消息中间件)
中间件，位置在中间，介于业务系统与底层组件（操作系统、数据库）之间。直接操作底层组件，为业务系统提供便利
缓存中间件：memcache、redis
消息中间件(MQ)：ActiveMQ、RabbitMQ、Kafka
数据库读写分离、搜索引擎、缓存
垂直分库、水平分库分表
多模块、面向服务SOA
分布式架构的难点与问题
1、第三种形态：超时、未知
2、分布式事务：跨节点事务，A节点成功，B节点失败
3、负载均衡
4、一致性
5、故障的隔离
SOA与微服务
SOA：面向服务架构。随着业务不断发展，系统越来越多，但前端的一个页面的展示内容，可能来自多个系统。后端多个服务，服务之间也会相互调用。怎么让系统清晰呢，SOA，引入了ESB，企业服务总线，多个服务都与企业服务总线交互。
这样带来的好处：
- 有序
- 复用
- 高效
SOA更加关注系统的集成
微服务：业务需要彻底组件化和服务化。没有ESB
SOA，通过ESB通信，所以各Service
领域驱动设计与业务驱动划分
Domain Driver Design
领域即范围，确定边界。从上而下，确定子系统范围。
子系统中，仍可继续划分领域，不同领域在不同包中。
领域设计更贴近于业务，可以与业务卖家都能接受的方式，进行沟通设计
与基于数据库的设计是不同的
CAP与BASE
参见：https://chenjinbo1983.iteye.com/admin/blogs/2431596
CAP：一致性（各分区数据一致）、可用性（即时返回）、分区容忍性（在出现网络分区(比如断网)的情况下，分离的系统也能正常运行）
一致性：
- 强一致性，12306票务
- 弱一致性，银行转账
互联网项目， P是必须满足的，虽然要么CP，要么AP
断网情况下，有分区可用，如果要求一定时间必须数据，即可用性，则一致性得不到保障
如果要求，数据必须得是一致的，那么就必须等待，等待了，就不是高可用了
BASE：
基本可用：和分区容忍性差不多，要求系统是可用的
软状态：由于无法达到，强一致性，所以会有一个软状态，比如支付中，交易处理中
最终一致性：能过消息队列，使消息必达，最终达到一致
Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）
分布式架构下的高可用
1、避免单点
- 负载均衡（软负载，硬负载（F5））
- 热备
- 多机房（两地三机房，同城灾备，异地灾备）
2、应用的高可用
- 故障监控（系统监控（CPU/内存）、链路监控、日志监控）
- 应用的容错设计、自我保护能力（服务降级、限流）
- 数据量（数据分片、读写分离）
CDN 架构及工作原理
step1：用户向localDNS发起请求查询输入域名对应的IP地址（若有缓存直接返回，否则去rootDNS查询）；
step2：localDNS迭代向rootDNS查询，逐级迭代,rootDNS=>顶级DNS=>权限DNS；
step3：获得权限DNS后，localDNS向权限DNS发起域名解析请求；
step4：权限DNS通常会将域名CNAME【如果有CNAME则解析CNAME对应的CDN服务，否则的话默认为普通请求，直接返回解析到的IP】到另一个域名，这个域名最终会被指向CDN网络中的智能DNS负载均衡系统；
step5：DNS负载均衡系统通过一些智能算法，将最合适的CDN节点IP地址返回给localDNS；
step6：localDNS将获得的IP地址返回给用户；
step7：用户得到节点的IP地址后，向该节点发起访问请求；
step8：CDN节点返回请求文件，如果该节点中请求的文件不存在，就会再回到源站获取这个文件，然后返回给用户。
网络基础知识
TCP/IP四层模型
TCP三次握手、四次挥手
Socket套接字
bio：阻塞IO ServerSocket
nio：非阻塞IO Selector Channel Buffer
Http：应用层协议，请求报文包括消息行、消息报文和报文体
Https：对HTTP协议传输的数据进行加密。在TCP之上加了一层，之前用的SSL（Secure Sockets Layer）,后来采用TLS（Transport Layer Security）
2.1 验证流程
注：文中所写的序号与图不对应但流程是对应的
1 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端
2 服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法
以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等。
3 客户端收到服务端响应后会做以下几件事
3.1 验证证书的合法性
颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等
证书验证通过后，在浏览器的地址栏会加上一把小锁(每家浏览器验证通过后的提示不一样 不做讨论)
3.2 生成随机密码
如果证书验证通过，或者用户接受了不授信的证书，此时浏览器会生成一串随机数，然后用证书中的公钥加密。
3.3 HASH握手信息
用最开始约定好的HASH方式，把握手消息取HASH值， 然后用 随机数加密 “握手消息+握手消息HASH值(签名)” 并一起发送给服务端
在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。
4 服务端拿到客户端传来的密文，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码 解密 握手消息与HASH值，并与传过来的HASH值做对比确认是否一致。
然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端
5 客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密
因为这串密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全
非对称加密算法：RSA，DSA/DSS 加密密钥和解密密钥不同
对称加密算法：AES，RC4，3DES 加解密密钥相同
HASH算法：MD5，SHA1，SHA256 在确认握手消息没有被篡改时
HTTPS关键在于CA证书。服务端发送了证书，客服端可验证证书的有效性，这就确认了服务端是合法性。加密码是客户端生成的，加密码通过公钥加密后，只能由服务端通过私钥解密，解密后，可以计算HASH握手消息，一致，说明客户端是合法的。