mongodb-driver更新库中某一字段的值
需求自己做的图床，上传的图片是没有后缀名的，写文章时，markdown是支持的，可以显示图片，但是，当我把文章复制到微信公众号时，却发现上传失败，手动加了后缀后，能显示，所以需要将图床上所有的图片加上“.jpg”后缀。
因为我使用一个mongo来存储的映射关系，所以第一步要修改mongo中的URL字段。
工作项目pom.xml，不想用springboot引入一大堆包，所以用了mongodb-driver。
123456789101112131415161718192021<dependency> <groupId>org.mongodb</groupId> <artifactId>bson</artifactId> <version>3.11.0</version> </dependency> <dependency> <groupId>org.mongodb< ...
深入了解Zookeeper【五】选举原理
1、概述Leader选举是Zookeeper保证分布式数据一致性的关键，上一篇简单的了解了Paxos算法和ZAB机制，本篇来简单学习一下选举原理。
2、节点角色Zookeeper集群中的服务器节点有3中角色：Leader、Follower、Observer。
2.1、LeaderLeader是Zookeeper集群中的核心，主要负责集群内部各个节点的调度，还要负责事务处理的顺序性。
2.1、Follower
Follower直接处理非事务请求，对于事务请求会交给Leader。
在Leader处理事务请求时，参与决策投票。
选举Leader时参与投票。
2.1、Observer不参与投票，只为了增加Zookeeper集群的非事务处理能力。必须在配置文件中指定哪些节点是Observer。
3、选举时机
集群中服务启动时会发生选举。
在集群运行过程中，Leader崩溃时会发生选举。
4、节点状态转换图中只涉及Leader与Follower。
5、投票的信息
属性
说明
id
被推举 Leader 的 sid
zxid
被推举 Leader 的事务ID
electionE ...
深入了解Zookeeper【四】Paxos算法与ZAB协议浅析
本文的目的是为了简单的了解一下这两个算法（机制）。
1、Paxos算法Paxos算法是一种基于消息传递且具有高度容错性的一致性算法。用于解决分布式系统中各个进程如何就某个值达成一致的问题。利用大多数机制，保证2N+1的容错能力，即系统中最多允许出现N个节点故障。
1.1、Paxos算法中的角色
提议者（Properser）提出议案（Proposal）,包括全局唯一且递增的Proposal ID和提议的值。
决策者（Accepter）参与决策，回应提议者的提案。若提案获得多数决策者的接受，则此提案被批准。
最终决策学习者（Learner）不参与决策，从提议者与决策者学习最新达成一致的提案。
多副本状态机中都有这三种角色：
1.2、Paxos算法简单流程一个完整的Paxos算法分为三个阶段：
Prepare阶段提议者向各个决策者发送Prepare请求，各个决策者针对收到的Prepare请求进行Promise承诺。
Accept阶段提议者收到多数决策者的promise后，向决策者发出Propose请求，决策者针对收到的Propose请求进行Accept处理。
Learn阶段提议者在收到多 ...
深入了解Zookeeper【三】Watcher机制
1、背景Zookeeper要想实时的获取ZNode的数据状态，如果轮询获取的话，实时性差，资源利用率低，浪费CPU资源，如果是Zookeeper服务端主动推送，会节省大量的资源。Zookeeper服务端通过Watcher机制来实现事件通知。
2、原理
Zookeeper客户端向Zookeeper服务端注册想要监听的节点状态。
客户端在WatchManager中本地存储监听器相关信息。
Zookeeper服务端监听的数据状态发生变化。
Zookeeper主动发送相应的事件信息给相关会话客户端。
客户端在本地响应式的回掉Watcher的process方法。
3、简单源码分析客户端使用Zookeeper主要关注两个类：org.apache.zookeeper.Watcher与org.apache.zookeeper.WatchedEvent。
3.1、org.apache.zookeeper.Watcher一般想要注册监听，先要实现Watcher接口里的process方法：
12345678910111213/** * 节点watcher */private Watcher baseN ...
深入了解Zookeeper【二】节点类型与分布式锁
1、节点类型Zookeeper是一个一致性的文件系统，保证了其每个节点的唯一性。有4种节点类型：
持久化目录节点客户端与Zookeeper断开后，该节点依旧存在。
持久化顺序编号目录节点保持持久化目录节点的特性外，每个节点的名称会被顺序编号。
临时目录节点客户端与Zookeeper断开后，该节点被删除。
临时顺序标号目录节点保持临时目录节点的特性外，每个节点的名称会被顺序编号。
顺序号是单调递增的计数器，由父节点维护。
2、分布式锁分布式锁就是利用了Zookeeper的临时顺序标号目录节点的原理来实现，Locks主节点下面的ID最小的节点获的锁的权限，其他客户端来获取锁时，发现自己不是最靠前的，会监视他的前一个锁节点，当锁释放时，相应的节点被删除，会通知这个等待的客户端，其获取锁的权利，相当于形成了一个等待队列。
Zookeeper分布式锁的优点就是有现成的框架可以拿来就用，因为有等待队列，枪锁的效率也会高。缺点是因为Zookeeper是类似文件系统的数据结构，所以删除和新增节点的效率会比较低。
深入了解Zookeeper【一】概述与工作机制
1、概述Zookeeper提供分布式应用协调服务，集群架构如图：
Zookeeper中有一个Leader，多个Follower。
集群中只要有半数以上节点存活，Zookeeper就能正常服务，这一点和Kafka集群的区别就是：Zookeeper并不存储大量数据，所以多台机器冗余，成本不是很高，即可以做到分布式系统的可用性。
Zookeeper能保证数据一致性，客户端连接到集群中哪一台服务器，数据都是一致的。
数据更新原子性。
在一定的时间范围内，能提供实时性，客户端能读取到最新的数据。
2、数据结构Zookeeper采用类似文件系统的层级树状结构进行数据的管理，树的节点称为ZNode,每个节点都是唯一的。
Zookeeper的数据存储可以通过客户端ZooInspector来查看，可以通过关注微信公众号ClawHub,回复关键字“zooInspector”获取。
3、应用场景Zookeeper的应用场景非常的多,包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线监控、软负载均衡、分布式锁等。
3.1、统一命名服务比如Dubbo可以通过Zookeeper来存储生产者与 ...
深入了解Kafka【五】Partition和消费者的关系
1、消费者与Partition以下来自《kafak权威指南》第4章。假设主题T1有四个分区。
1.1、一个消费者组1.1.1、消费者数量小于分区数量只有一个消费者时，消费者1将收到4个分区的全部消息。当有两个消费者时，每个消费者将分别从两个分区接受消息。
1.1.2、消费者数量等于分区数量当有四个消费者时，每个消费者都可以接受一个分区的消息。
1.1.3、消费者数量大于于分区数量当有五个消费者时，会有闲置的消费者。
1.2、两个消费者组消费者群组之间是互不影响的，如图：
2、分区分配策略当消费者加入群组的时候，会根据分区分配策略决定哪些分区分配给哪些消费者。Kafka有两种分配策略：Range和RoundRobin。
RangeTopic的若干个连续的Partition分配给消费者。
RoundRobinTopic的所有Partition逐个分配给消费者。
3、分区Rebalance(再均衡)
有新的消费者加入消费者群组
已有的消费者退出消费者群组
订阅的主题的分区发生变化
以上三种情况都会触发分区的重新分配，重新分配的过程叫Rebalance(再均衡)。Rebalance给消费 ...
深入了解Kafka【四】消费者的Offset管理
1、Offset TopicConsumer通过提交Offset来记录当前消费的最后位置，以便于消费者发生崩溃或者有新的消费者加入消费者组，而引发的分区再均衡操作，每个消费者可能会分到不同的分区。我测试的kafka版本是：0.11.0.2，消费者往一个特殊的主题“_consumer_offset”发送消息，如图：
消息的内容包括：
fields
content
Key
Consumer Group, topic, partition
Payload
Offset, metadata, timestamp
提交到“_consumer_offset”主题的消息会根据消费组的key进行分区，一个消费组内的所有消息，都会发送到唯一的Partition。
2、Offset CommitOffset的提交逻辑其实和普通的生产者往kafka发送数据是一样的。
2.1、Consumer消费者启动时会为“_consumer_offset”主题创建一个内置的生产者，用于Offset数据的提交。
2.2、Broker就是将Offset提交当成是正常的生产请求，逻辑不变。
“_consum ...
深入了解Kafka【三】数据可靠性分析
1、多副本数据同步策略为了保障Producer发送的消息能可靠的发送到指定的Topic，Topic的每个Partition收到消息后，要向Producer发送ACK,如果Producer收到ACK，就会进行下一轮发送，否则重试。
1.1、多副本概述为了提高消息的可靠性，Kafka每个Topic的partition都有N个副本（replica）。这N个副本中，其中一个replica是Leader，其他都是Follower。Leader负责处理Partition的所有请求，Follower负责同步Leader的数据。下图展示了Kafka集群中的4个Broker，Topic有3个Partition。
1.2、同步副本队列ISRPartition什么时候才会发送ACK呢?要确保全部的Follower与Leader同步完成之后，Leader才能发送ACK,这样才能保证Leader挂掉之后，在所有Follower中能选出新的Leader。但是万一有一个Follower因为故障，迟迟不能和Leader同步，Leader就得等着它完成同步之后才能发送ACK,怎么决解呢？这就引出了ISR(in-sy ...
深入了解Kafka【二】工作流程及文件存储机制
1、Kafka工作流程Kafka中的消息以Topic进行分类，生产者与消费者都是面向Topic处理数据。Topic是逻辑上的概念，而Partition是物理上的概念，每个Partition分为多个Segment,每个Segment对应两个文件，一个索引文件，一个日志文件。Producer生产的数据会被不断的追加到日志文件的末端，且每条数据都有自己的offset。消费组中的每个Consumer都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。
2、文件存储机制由于Producer产生的消息会不断的追加到日志文件的末尾，这样将对消息文件的维护以及以消费的消息的清理带来严重的影响，因此，Kafka引入的分片和索引的设计。每个Partition对应一个文件夹；“topic名称+分区序号”。每个Partition分为多个Segment,Segment分为两类文件：“.index”索引文件与“.log”数据文件，其中索引文件和数据文件都在Partition对应的文件夹中。假设test-topic有3个分区，则对应的文件夹名称为：test-topic-0、test-to ...
