1.Elasticsearch 源码探究 ——故障探测和恢复机制
2.Rocketmq5.1.3 自主选举\切换 集群k8s部署实践(万字长文)
3.eos全家桶系列eos系统合约介绍—系统操作合约eosio.system(上)
4.zookeeper是选举选举序图什么？
Elasticsearch 源码探究 ——故障探测和恢复机制
Elasticsearch 故障探测及熔断机制的深入探讨
在Elasticsearch的7..2版本中，节点间的源码故障探测及熔断机制是确保系统稳定运行的关键。故障监测主要聚焦于服务端如何应对不同场景，选举选举序图包括但不限于主节点和从节点的源码故障，以及数据节点的选举选举序图离线。
在集群故障探测中，源码freeeim源码源码时代Elasticsearch通过leader check和follower check机制来监控节点状态。选举选举序图这两个检查通过名为same线程池的源码线程执行，该线程池具有特殊属性，选举选举序图即在调用者线程中执行任务，源码且用户无法直接访问。选举选举序图在配置中，源码Elasticsearch允许检查偶尔失败或超时，选举选举序图但只有在连续多次检查失败后才认为节点出现故障。源码
选举认知涉及主节点的选举选举序图选举机制，当主节点出现故障时，会触发选举过程。通过分析相关选举配置，可以理解主节点与备节点之间的屌丝模板源码切换机制。
分片主从切换在节点离线时自动执行，该过程涉及状态更新任务和特定线程池的执行。在完成路由变更后，master节点同步集群状态，实现主从分片切换，整个过程在资源良好的情况下基本为秒级。
客户端重试机制在Java客户端中体现为轮询存活节点，确保所有节点均等机会处理请求，避免单点过载。当节点故障时，其加入黑名单，客户端在发送请求时会过滤出活跃节点进行选择。
故障梳理部分包括主master挂掉、备master挂掉、单个datanode挂掉、活跃master节点和一个datanode同时挂掉、服务端熔断五种故障场景，以及故障恢复流程图。引导页源码最新每种场景的处理时间、集群状态变化、对客户端的影响各有不同。
最佳实践思考总结部分包括客户端和服务器端实践的复盘，旨在提供故障预防和快速恢复策略的建议。通过深入理解Elasticsearch的故障探测及熔断机制，可以优化系统设计，提高生产环境的稳定性。
Rocketmq5.1.3 自主选举\切换 集群k8s部署实践(万字长文)
在Rocketmq 5.1.3的部署实践中，由于官方未提供k8s镜像，我遇到启动失败和配置限制等问题。因此，我选择自定义镜像并调整部署策略。首先，我使用JDK 1.8u和Ubuntu 作为基础镜像，通过下载官方推荐的版本并在docker中构建自己的Rocketmq镜像。下载过程中，需注意Oracle JDK的html发邮件源码下载链接问题，可以直接复制获取无需注册。
在镜像制作过程中，我从官方下载5.1.3版本的Rocketmq源码和二进制包，然后在容器中部署，参考官方快速开始指南，将包解压至指定目录，并创建链接。为支持自定义配置，我修改了源码，特别是使用RMQ_HOME替代硬编码的$user.home$，并重新构建了项目。具体涉及的文件包括jar和xml，以及日志配置，通过docker cp命令将这些文件替换到容器中。
我调整了启动脚本，引入环境变量以检查和创建必要的目录，确保服务在没有配置时仍能启动。最后，dgc拆分盘源码通过验证nameserver和broker的启动成功，确认部署的稳定性。镜像制作完成后，我将其上传到私服，标签为registry:/middleware/rocketmq5.1.3，用于后续的k8s部署。
在k8s部署方面，我提供了详细的yaml文件，包括nameserver和brokerserver的配置。对于Rocketmq管理工具的dashboard，我建议使用官方镜像并在必要时通过私有镜像库解决拉取问题。部署成功后，用户可以在界面上看到运行的集群。
虽然过程较长，但通过本文，希望对你的k8s部署Rocketmq有所帮助。如果你觉得文章有价值，欢迎点赞支持。同时，我提供技术咨询服务，包括可行性分析、架构设计等，可以在知乎付费或淘宝下单获取服务。
eos全家桶系列eos系统合约介绍—系统操作合约eosio.system(上)
本篇文章旨在详细介绍EOS系统中至关重要的系统操作合约——eosio.system。该合约负责处理包括账户创建、投票选举超级节点、资源质押和域名竞拍等多种功能。本文将重点阐述eosio.system合约在资源质押和超级节点投票方面的具体实现。
EOS网络中的超级节点选举和投票机制均以账户为中心展开。eosio.system合约中的投票功能可通过cleos system命令行工具便捷地执行。投票过程涉及两个主要角色：投票账户和候选超级节点账户。它们必须遵循特定的步骤才能完成投票或当选：
**步骤一：抵押EOS资源
**抵押EOS资源以换取cpu和net资源是投票前的必要条件。使用delegatebw命令，指定抵押EOS的账户和接收抵押资源的账户。
**步骤二：注册为超级节点候选账户
**注册为超级节点候选账户需要提供公钥，该公钥用于当选后产块时的签名验证。
**步骤三：投票给超级节点候选账户
**通过voteproducer命令，投票账户可以为多个超级节点候选账户投票。投票账户可以取消投票通过赎回质押的EOS，赎回期为3天。
下面将演示赎回质押EOS的步骤：
**步骤一：取消质押
**使用undelegatebw命令取消质押，该命令与delegatebw命令相似。在某些情况下，例如本机私链，赎回期可被调整，质押的EOS将在指定时间后赎回到账。
**步骤二：源码解析
**delegatebw和undelegatebw命令最终都会调用changebw方法。changebw根据操作类型进行相应的资源转移或赎回操作。
**步骤三：投票权重衰减与更新
**为了鼓励用户定期投票，EOS引入了投票权重衰减机制。用户需定期重新投票以维持其投票权重，确保投票效力不受影响。
本文简要介绍了eosio.system合约在资源质押和超级节点投票方面的核心功能及其背后的源码实现。接下来，我们将探讨eosio.system合约在域名竞拍方面的功能，敬请期待。
zookeeper是什么？
zookeeper是动物管理员的意思。 ZooKeeper是一个分布式的，开放源码租前慎的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括:配置维护、域名服务、分布式同步、组服务等。 ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper包含一个简单的原语集，提供Java和C的接口。 ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在$zookeeper_home\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。 它的原理： ZooKeeper是以Fast Paxos算悔判法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有弊敬可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos做了一些优化，通过选举产生一个leader (领导者)，只有leader才能提交proposer，具体算法可见Fast Paxos。因此，要想弄懂ZooKeeper首先得对Fast Paxos有所了解。 ZooKeeper的基本运转流程:1、选举Leader。2、同步数据。3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。4、Leader要具有最高的执行ID，类似root权限。5、集群中大多数的机器得到响应并接受选出的Leader。