Merge pull request KeKe-Li#766 from KeKe-Li/feature-keke

feat: update chapter

Author: KeKe-Li

src/chapter05/golang.01.md

@@ -6824,7 +6824,6 @@ LVS的由2部分程序组成，包括 Ipvs 和 Ipvsadm。
 <img width="500" align="center" src="../images/175.jpg" />
 </p>
 
-
 Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等。
 
 一个商业化消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。
@@ -7013,21 +7012,18 @@ CAP原则，指的是在一个分布式系统中，Consistency(一致性)、Avai
 * 可用性（Availability）：每次请求都可以得到一个响应，但是得到的数据不一定是最近的数据。
 * 分区容错性（Partition tolerance）：当系统中有节点因网络原因无法通信时，系统依然可以继续运行。
 
-
 可用性容易与分区容错性相混淆，这两个概念都是保证系统可以持续对外提供服务。但是两个概念侧重点不同，可用性是保证系统中某些节点故障的情况下系统可用，而分区容错性是保证系统出现网络分区即某些节点相互通信失败的情况下，系统依然可用。
 
 CAP定理定义了这三个属性之间的相互关系：根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。这样就产生三种取舍情况：CA（withoutP）、CP（withoutA）、AP（withoutC）。
 
 CA：这种情况相当于只满足可用性和一致性，不在满足分区容错性。在现实世界中，分布式系统中节点之间的网络异常不可避免。所以如果不保证分区容错性，除非节点间永不发生网络异常，显然这样不可能【注2】。或者极端一点的假设是不存在网络通信，那整个节点就变成单一节点的单机系统。所以，单纯的CA分布式系统并不存在。
 
-
 CP：当系统中出现网络分区的情况时，我们选择保证一致性，这时请求就会等待，直到问题节点网络异常恢复。
 
 AP：当系统出现网络分区的情况时，我们选择保证可用性，此时所有节点可以正常响应请求，但由于节点之间不能相互联络，节点只能用本地数据响应请求，此时节点间本地数据有可能不同步，为了保证高可用，我们放弃了一致性
 
 MySQL主从复制模式就是典型的AP应用场景，当主从节点产生网络延时致使从节点数据不能及时同步时，我们无需等待网络恢复，依然可以继续访问从节点获取数据。因而需要根据自己的服务做一个预期选择对应的原则。
 
-
 #### Golang面试参考
 
 * [Golang调度](http://morsmachine.dk/go-scheduler)