前置内容 掌握策略模式 掌握责任链模式 掌握类继承、接口的实现 掌握参数的传递与设置 GitHub地址 ps：【文章由来】 公司项目中所用的合同签章处理流程，本人基于责任链上使用策略模式进行优化。 签章的处理流程 合同文本初始化 合同文本生成 签章挡板是否开启 合同签章发送mq 合同签章流水更新 合同上传文件服务器 签章渠道选择 签章渠道的实际调用 执行的流程如下： 整个结构类似于递归调用。每个节

图 在离散数学中，图（Graph）是用于表示物体与物体之间存在某种关系的结构。数学抽象后的“物体”称作节点或顶点（英语：Vertex，node或point），节点间的相关关系则称作*边**。[1]在描绘一张图的时候，通常用一组点或小圆圈表示节点，其间的边则使用直线或曲线。 -----------维基百科* 上面这段话表明图就是由一个个的节点和节点间的关系（边）构成的。节点与节点的关系可以是单方向的

1.Redis 主从复制 1.1.用途 1、Redis 主从是构建redis集群最基础的操作 2、读写分离，扩展主节点的读能力，分担主节点读压力 1.2.redis 一主两从搭建 1、Redis 安装（3个节点都要） yum install -y gcc-c++ autoconf automake cd /usr/local/ wget http://download.redis.io/redis

1.Redis集群模式介绍 Cluster模式是Redis3.0开始推出的 Redis Cluster属于AP模型 采用无中心结构，每个节点保存数据和整个集群状态, 每个节点都和其他所有节点连接 官方要求：至少6个节点才可以保证高可用，即3主3从；扩展性强、更好做到高可用 各个节点会互相通信，采用gossip协议交换节点元数据信息 数据分散存储到各个节点上 2.集群和哨兵的区别 Sentinel哨

1.介绍 本文主要介绍ES分布式的一些原理，了解一个文档的写入、提取、搜索在ES里面做了哪些事情。 2.文档写入流程 我们首先了解在ES集群中，一个单独的文档是如何写入的。 1、客户端发送任何一个请求到任意一个节点，这个节点就成为协调节点 （coordinate node） 2、协调节点对新增document（可以手动设置doc id，也可以由系统分配）的id号进行哈希取值，在根据分片的数量进行取

当你没有使用swarm时候，使用是docker的命令，如果使用swarm这使用的是swarm提供的一些命令服务编排进行操作，可以但节点使用或者集群服务。尽管这些服务大多数是无状态的，但是，我们应该明白，一旦使用集群那么很多东西都需要进行考虑，比如存储方案，使用本地存储还是跨主机存储，如何进行选型等，镜像参考，编排工具等。总而言之，swarm也是很好的选择，我们可以进行简单安装和配置。 Swarm守

swarm可以轻松的发布服务和端口，所有节点都参与入口的路由网络，路由网络能够使得集群中每个节点都能够接受已经发布端口上的任何服务。即使在节点上没有运行任何服务，也可以在集群中运行任何服务。路由网络将所有传入请求路由到可用节点上，也就是存活的容器上。 扩展阅读：https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/#t

集群节点中的每一个节点，或者选择器节点，运行“某个”指定的POD副本，通常用来实现系统级的管理功能，或者后台任务，可以将节点上的某个目录作为存储卷关联至POD中，让pod实现某些管理功能。并且在新加入的node节点自动添加此类的pod副本，其中也需要标签选择器的使用。并且daemonSet也支持滚动更新！这类服务通常无状态，以守护进程运行 参数 updateStrategy: 更新策略(默认滚动更

在kubernets中运行pod资源的节点中，master节点运行控制组件，主要控制组件如： apiserver controller-manager scheduler 除此之外，master还依赖ETCD存储节点，或者是一个有冗余能力的存储集群。在使用kubeadm部署时候，这些组件会被运行成pod应用程序，并且是静态pod。简单的讲，就是运行在master本地的一个守护进程。从这个方面讲，m

之前的scheduler，默认的default scheduler分三部实现调度过程，首先是预选，从所有节点当中选择基本符合选择条件的节点，而后在众多基本符合选择条件的节点中通过优选函数，对这些节点加以比较。并且从最高得分当中随机选择一个作为运行pod的节点。这就是scheduler负责的功用。 高级调度机制 节点调度 在某些调度参加中，可通过自己的预设来影响预选，优选的过程，从而使得调度的操作符

Pod自身的亲和性调度分为两种表示形式，第一种podinity(亲和性)，第二张podAffinity(反亲和性) pod亲和性 pod与pod更倾向运行在一起。一般出于高效通讯的需求把pod对象组织在相近的位置，同一个节点，同一个机架，同一个机房，甚至于同一个区域或者地区，便于pod通讯。但是有些时候在部署两套系统的时候，出于一些安全或者其他的考虑，不能够部署在一起的时候，就需要反亲和性。 po

在前面的两种方式中，都是由pod去选择的，节点被动选择运行。而污点调度方式就给了节点的选择权。让节点可以选择让那些pod运行在节点上。总的来说，污点就是定义在节点上的键值属性数据。 此前，我们知道，键值属性有三类，第一类叫标签，第二类叫注解，第三类便是污点。污点用在节点之上，而前两类所有资源对象都可以使用。 pod亲和性和node亲和性都是pod的属性，而污点是节点的属性 污点也是一种键值属性，主

prometheus metrics-server可以对核心指标进行监控。 除开节点，podCPU内存之外的其他指标是无法获取的，就要借助prometheus。 prometheus提供的资源指标是不能够被k8s解析的，要想能在k8s上使用prometheus， 就需要额外加一个prometheus的资源转换，转成k8s api能够兼容的格式，才能被当作指标数据使用。 架构形式如下： promet

简单的进行初始化 1，安装相同版本的docker,复制必要的镜像文件到node节点导入2，同步时间3，将桥接的IPv4流量传递到iptables的链 cat > /etc/sysctl.d/k8s.conf << EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 n

activemq官网提供三种集群方式，Shared File System Master Slave，JDBC Master Slave，Replicated LevelDB Store，本章采用最后一种http://activemq.apache.org/masterslave.html ,官网是不建议使用LevelDB，推荐使用kahaDB集群方式: 依靠Apache ZooKeeper协调节

在此前的两个版本中，不同于数据库集群大小和数据大小做了不同的线上测试，有一系列问题，最终被下架更换到haproxy。在新的环境中使用了2.4，因为2.4有很多变动。仍然保持热情的进行体验。Galera cluster集群模式中节点都可以作为读写，但是通常而言，会在一台节点进行写入，其他节点读取。因此选择读写分离模块readwritesplit路由模式。 readwritesplit 读写分离rea

mongodb复制集是原生提供这种方式 ，复制集的主要意义在于实现服务的高可用，它的依赖于两个方面的功能 输入写入时将数据快速复制到另外一个独立节点上 在接受写入的节点发生故障时自动选举一个新的替代节点 在实现高可用的同时，复制集实现了其他几个附加的作用 数据分发： 将数据 从一个区域复制到另一个 区域，减少另一个区域的读延迟 读写分离：不同类型的压力分别在不同的节点上执行 异地容灾：在数据中心故

1 有来有回 有正向就有逆向。例如在处理交易链路时，仅仅考虑正向链路是不够的。逆向链路是指如果用户发起售后应当如何处理，否则业务不闭环。 2 有正有负 有正常就有异常。例如在处理交易链路时，假设需要经过10个业务节点，如果这些节点都不发生异常自然是好的。 但是架构设计必须考虑异常情况，例如第5个节点是扣减优惠券，但是扣减失败，那么前4个节点应该如何处理，这是必须回答的问题。 3 有始有终 有开始就

二叉树是一种树状结构，每个节点都包含自身的数据，指向左子节点和右子节点的指针。  // 这是用链式存储的二叉树，也可以使用数组来存储，如 heap  type Node struct {     Data        int     Left, Right *Node  } 遍历二叉树 二叉树根据遍历顺序的不同分了四种，分别是前序遍历，中序遍历，后序遍历和宽度优先遍历，前面三种遍历方式是深度优先

近期，在机器上部署了三个节点的nacos集群服务用于几个小型微服务的注册配置中心，并使用了Nginx简单代理了一下，随即简单研究了下集群部署分布式部署稍微提高可用性。部署完后能够正常使用，但是发现一个问题，刷新Nacos集群节点列表，总会有一个或者两个节点时不时处于DOWNh或者SUSPICIOUS状态，于是开始了漫长的查找问题过程。集群能够正常使用，就是各服务应用总会爆出来一堆链接nacos服务