ZK

这段时间来，也在和公司里的一些同学交流使用zk的心得，整理了一些常见的zookeeper问题。这个页面的目标是解答一些zk常见的使用问题，同时也让大家明确zk不能干什么。页面会一直更新。 1. 客户端对ServerList的轮询机制是什么 随机，客户端在初始化( new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher) )的过程中，将所有Server保存在一个List中，然后随机打散，形成一个环。之后从0号位开始一个一个使用。 两个注意点：1. Server地址能够重复配置，这样能够弥补客户端无法设置Server权重的缺陷，但是也会加大风险。（比如: 192.168.1.1:2181,192.168.1.1:2181,192.168.1.2:2181). 2. 如果客户端在进行Server切换过程中耗时过长，那么将会收到SESSION_EXPIRED. 这也是上面第1点中的加大风险之处。更多关于客户端地址列表相关的，请查看文章《 ZooKeeper客户端地址列表的随机原理 》 2 .客户端如何正确处理CONNECTIONLOSS(连接断开) 和 SESSIONEXPIRED(Session 过期)两类连接异常 在ZooKeeper中，服务器和客户端之间维持的是一个长连接，在 SESSION

zk搭建伪集群或者起个单个的都行。 我用版本是apache-zookeeper-3.5.5-bin https://my.oschina.net/u/3730149?tab=newest&catalogId=6535930 启动server: bin/zkServer.sh start Server启动之后, 就可以启动client连接server了, 执行脚本: #bin/zkCli.sh -server zkServer的ip:zkServer的port bin/zkCli.sh -server localhost:2181 1、创建znode 用给定的路径创建一个znode。flag参数指定创建的znode是临时的，持久的还是顺序的。默认情况下，所有znode都是持久的。 当会话过期或客户端断开连接时，临时节点（flag：-e）将被自动删除。 顺序节点保证znode路径将是唯一的。 ZooKeeper集合将向znode路径填充10位序列号。例如，znode路径 /myapp 将转换为/myapp0000000001，下一个序列号将为/myapp0000000002。如果没有指定flag，则znode被认为是持久的。 语法 create path data 示例 create /FirstZnode “Myfirstzookeeper-app" 输出 [zk:

前言背景 算法优化改版有大需求要上线，在线特征dump数据逐步放量，最终达到现有Kafka集群5倍的流量，预计峰值达到万兆网卡80%左右(集群有几十个物理节点，有几PB的容量，网卡峰值流出流量会达到800MB左右/sec、写入消息QPS为100w+ msgs/sec)。上下游服务需要做扩容评估，提前做好容量规划，保障服务持续稳定运行 L3层 dump特征 @xxx 1.依赖文章特征公共服务 2.依赖用户特征公共服务 前期可以一起共建 评估dump特征数据量 @xxx kafka新增Topic接收dump数据，评估kafka是否需要扩容 @xxx 新增拼接数据流支撑dump特征，需要评估新增机器 @xxx 经过对Kafka集群软硬件资源及利用率综合分析与评估，决定不扩容机器，完全可以应对流量扩大5倍的性能挑战 流量灰度时间表 2020-02-21放量进度 流量灰度10% 2020-02-24放量进度 流量灰度30% 2020-03-02放量进度 流量灰度50% 2020-03-02放量进度 流量灰度70% 2020-03-03放量进度 流量灰度85% 2020-03-05放量进度 流量灰度100% 优化纪实 预先优化在topics创建的情况下，没有流量时做的优化工作 本次在线特征dump放量topics列表如下： onlinefeedback indata_str

前言 dubbo是一个成熟且被广泛运用的框架。饶是如此,在某些极端条件下基于dubbo的应用还会出现无法重连zookeeper的问题。由于此问题容易导致比较大的故障，所以笔者费了一番功夫去定位，现将排查过程写成博文分享出来。 Bug现场 这是一起在测试环境出现的故障。起因是网工做交换机切换演练，可能由于姿势不对，使得断网的时间从预估的秒级达到了分钟级。等网络恢复后，测试环境就炸开了锅，基本上所有应用再也无法提供服务，在dubbo控制台上也看不到任何提供者，他们和zk的连接都断开而且似乎完全没有重连的迹象。如下图所示: 无法快速恢复 为了不影响测试的进度，运维同学紧急进行了重启，但坑爹的是大部分系统都有启动依赖，盲目的重启只会因为xxx provider不存在而无法启动。只能从最基础的服务开始重启，慢慢恢复。如下图所示: 还好只是测试环境，但为了不让产线出现这种问题，必须一查到底，把这个Bug揪出来。 着手排查 模拟zookeeper连接断开 测试环境的好处是我们可以用各种手段去模拟复现，而不用和处理产线一样到处寻找蛛丝马迹然后进行逻辑推理(推理是一个非常烧脑的过程)。于是笔者联系了SA同学，通过iptables进行线下的断网模拟。命令如下所示: // 禁用本机和zk三台机器的流量进出 iptables -A INPUT -s zk-1-ip/32 -j DROP iptables

Ubuntu16.04部署supervisor 安装supervisor: apt-get install -y supervisor 启动supervisor: systemctl start supervisor 设置开机自启动: systemctl enable supervisor 编辑配置文件: 实例: supervisor 配置文件 编辑配置文件： vim /etc/supervisor/supervisord.conf 添加：（开启supervisor网页功能） [inet_http_server] port=0.0.0.0:9001 username=user password=123 添加进程配置文件 cd /etc/supervisor/conf.d/ zookeeper为例： vim zk.conf --------------------------------------------------------- [program:zk] command = /usr/zookeeper-3.4.10/bin/zkServer.sh start-foreground environmen=JAVA_HOME="/usr/jdk1.8" user = root autostart = true autorestart = true startsecs = 5

概述 RPC框架是云端服务基础框架之一，负责云端服务模块之间的项目调用，类似于本地的函数调用一样方便。常见的RPC框架配带的功能有： 编解码协议。比如protobuf、thrift等等。 服务发现。指服务提供者更新接口后，服务使用者如何知道该接口更新。Protobuf协议使用的是预编译方式，dubbo中使用的是zk作为媒介。 负载均衡。 流量控制、熔断。 运维工具。 常见RPC框架有 谷歌的GRPC。 百度的BRPC。 阿里的dubbo。 脸书的thrift。 腾讯的tars。 本系列主要教大家如何实现RPC框架，使用的语音是C++，协议使用的是protobuf。 基于protobuf的RPC框架 这里不介绍具体protoc的使用方法，网上很多。在完成protoc编译后，会输出protobuf提供的服务框架中，主要有如下几个类 Controller，主要是rpc通信过程的辅助接口，记录错误状态和简单的控制。 Service，指特定的一个服务。在protobuf中，一个服务（service）可以包含多个方法（method），通过service+method可以唯一确定一个过程。 Channel，指使用者和提供者直接的连接通道，是protobuf的核心，但是rpc框架开发者一般不直接调用该类，而是调用下面的stub（桩/存根）。 Stub，客户端使用的存根，通过该类去发起远程过程调用

ZooKeeper是一个分布式的、开源的分布式应用程序协调服务，可以在分布 式环境中实现应用配置管理、统一命名服务、状态同步服务等功能。 ZooKeeper是一种为分布式应用所设计的高可用、高性能的开源协调服务，它提供了一项基本服务：分布式锁 服务。由于ZooKeeper开源的特性，在其分布式锁实现的基础上，又被摸索出了其它的功用，譬如：配置维 护、组服务、分布式消息队列等等。 ZooKeeper维护了一个类似文件系统的数据结构，其内部每个子目录都被 称作znode（目录节点），与文件系统一样，我们可以自由的增删改查znode。ZooKeeper集群适合搭建在奇数 台机器上。只要集群中半数以上主机处于存活，那么服务就是可用的。 ZooKeeper在配置文件中并没有指定 master和slave，但是，ZooKeeper在工作时，只有一个节点为leader，其余节点为follower，leader是通过内部 的选举机制临时产生的。 ZooKeeper特点 1、顺序一致性：以zxid来保证事务的顺序性。 2、原子性：以zab保证原子操作，要么成功，要么失败。 3、单一视图：客户获取到的数据始终是一致的。 4、可靠：以版本实现"写入校验"，保证了数据写入的正确性。 ZooKeeper有三种安装方式：单机模式 & 伪集群模式 & 集群模式 单机模式： ZooKeeper以单实例的形式运

hadoop: hdfs:分布式存储 MR： 分布式计算 hdfs: ========================= 1、namenode(元数据)、datanode(真实数据)、2nn(检查点) 2、hadoop-daemon.sh start namenode //启动本机进程 hadoop-daemons.sh start datanode //启动slave机器进程 3、namenode:编辑日志(hdfs oev)和镜像文件(oiv) 编辑日志：hdfs对文件的写操作，读取文件不需要修改编辑日志 镜像文件：hdfs文件的元数据，即索引 4、datanode:真实数据、校验和(7字节的头部+每个chunk512字节进行的4字节校验) 5、2nn: 每个3600s对namenode中的数据进行备份 编辑日志和镜像文件的融合： =============================== 1、每进行一次写操作，编辑日志的id都会+1，保存在edits_inprogress中 2、在namenode启动的时候： namenode处于安全模式状态(safemode),此模式下文件只可读不可写 edits_inprogress实例化为编辑日志文件 老镜像文件和比镜像文件id数大的编辑日志文件加载到内存，重新操作编辑日志的所有操作步骤，并产生新镜像文件 融合过后

1 Zookeeper介绍 ZooKeeper是为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务： 分布式锁服务。分布式应用可以基于它实现更高级的服务，实现诸如同步服务、配置维护和集群管理或者命名的服务。 Zookeeper服务自身组成一个集群，2n+1个（奇数）服务允许n个失效，集群内一半以上机器可用，Zookeeper就可用。 1.1 数据模型 1）ZooKeeper本质上是一个 分布式的小文件存储系统； 2）Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点）， 每个节点可以存少量的数据（1M左右）。 3）每个节点称做一个ZNode。 每个ZNode都可以通过其路径唯一标识。 4）ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说 读操作将获取该节点相关的所有数据，写操作也将替换掉节点的所有数据。 5）在zookeeper创建顺序节点（create -s ），节点路径后加编号，这个计数对于此节点的父节点来说是唯一的。 /app/ /s100000000001 /s100000000002 6）ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。 ① 临时节点 ：在客户端用 create -e创建

3 月，跳不动了？>>> 本次分享的内容主要包括五个大部分： Redis、RedisCluster和Codis; 我们更爱一致性; Codis在生产环境中的使用的经验和坑们; 对于分布式数据库和分布式架构的一些看法; Q & A环节。   Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正。 一、 Redis，RedisCluster和Codis    Redis ：想必大家的架构中，Redis已经是一个必不可少的部件，丰富的数据结构和超高的性能以及简单的协议，让Redis能够很好的作为数据库的上游缓存层。但是我们会比较担心Redis的单点问题，单点Redis容量大小总受限于内存，在业务对性能要求比较高的情况下，理想情况下我们希望所有的数据都能在内存里面，不要打到数据库上，所以很自然的就会寻求其他方案。 比如，SSD将内存换成了磁盘，以换取更大的容量。更自然的想法是将Redis变成一个可以水平扩展的分布式缓存服务，在Codis之前，业界只有Twemproxy，但是Twemproxy本身是一个静态的分布式Redis方案，进行扩容