「这是我参与2022首次更文挑战的第20天，活动详情查看：2022首次更文挑战」
-
zookeeper 注册中心
-
dubbo 服务发现和调用
-
docker
docker images
docker pull 下载容器
docker run -di --name=xxx -p xxx 制作容器
docker start 哈希码
docker ps -a 查看启动的容器
-
springCloud
-
注解：
@restController
@CrossOrigin 给不同微服务之间调用的
@RequestMapping
@RestControllerAdvice AOP增强 搭配下面的方法：@ExceptionHandller
-
JPA的东西：
@Entity @table（name = ''）指向一个数据库的表PO类
dao层Extends JPArepository
-
zuul hystix fegin eruka
-
-
一致性算法：
为了解决数据一致性，尤其是分布式下分区，脑类情况下（不同机房）某一个区崩溃了，也还是能够保证数据一致性。
Paxos、raft、zab
-
paxos
提议者proposer：提出提案
决策者acceptor：参与决策，接受提议者的提案，如果这个提案获得大多数决策者同意，那么就称该提案被批准。
最终决策学习者leaner
-
一致性hash算法：
原来我们要保存一张图片，会把这个图片进行hash然后，对服务器的数量进行取模，确定落到哪台机上。但是如果我们增加了一台服务器，取模的数字变了，原来落在服务器A的照片就跑到B去了，如果是缓存，查找的时候就去B上去找了，而B是没有的，就需要去后台找，导致缓存雪崩。
哈希一直算法就是有一个哈希换长度是2^32，首先制定好各个服务器所在的位置，然后我们计算完要查询或者保存的文件的hash，之后对2^32取模，确定他在什么位置，顺时针到下一个服务器，这个服务器就是他要去找的服务器。
这种样式可以减少很大一部分增加了服务器（增加了一台服务器，就指定在环上的一个地方），图片保存的服务器位置变了的情况。
D是新增加的节点，也就是Cd之间的文件会重新落到不同服务器，但是其他的并不会。
其实你也看出来，他的最大问题就是如果节点数量不够，分布不均会导致hash倾斜，这样要重新确定服务器的数量还是很多。办法就是，创建更多的节点，当你的服务器数量并不是很多的时候，你可以创建虚拟映射节点。
-
