Zookeeper--概述及应用

  ZookeeperHadoop 的分布式协调服务,起源于Google的Chubby。分布式应用程序可以基于它实现同步服务,配置维护和命名服务等。Zookeeper 可以保证数据在Zookeeper 集群之间的数据的事务性一致。

总体概述

ZooKeeper总体架构

  1. 组成: ZooKeeper集群即多个Server节点其中有一个Leader的节点,和多个Follower组成
  2. 写请求: 当客户端Client执行写请求时,会发送到Leader节点上,然后Leader节点上数据变更会同步到集群中其他的Follower节点。Leader节点在接收到数据变更请求后,首先将变更写入本地磁盘,以作恢复之用。当所有的写请求持久化到磁盘以后,才会将变更应用到内存中。
  3. 协议: ZooKeeper使用了一种自定义的原子消息协议,在消息层的这种原子特性,保证了整个协调系统中的节点数据或状态的一致性和本地的ZooKeeper数据与Leader节点同步。
  4. 选举: 当Leader节点发生故障,消息层负责重新选举出Leader,继续作为协调服务集群的中心,处理客户端写请求。

Zookeeper--集群搭建

  zookeeper集群搭建,是非常简单的。本博客就简单的记录一下,不详细的说每一个步骤了。主要就是下载后解压,修改配置,拷贝到其他节点,该一下myid中的编号后启动即可。

单机模式:

  1. 下载zookeeper-3.4.6.tar.gz:上传到服务器目录
  2. 解压到指定目录:tar -zxvf zookeeper-3.4.6.tar.gz -C /usr/local/zookeeper
  3. cd zookeeper/conf
  4. 修改配置文件名称:mv zoo_sample.cfg zoo.cfg
  5. cd ..
  6. 启动zookeeper:bin/zkServer.sh start
  7. 验证:jps,看到有这个(QuorumPeerMain)进程就表示zookeeper已经正常启动。

Redis--优化详解

  本片博客,刚开始会讲解一下redis的基本优化,然后会举一些优化示例代码或实例。最后讲解一下,默认启动redis时,所报的一些警示错误

优化的一些建议

  1. 尽量使用短的key
    当然在精简的同时,不要完了key的“见名知意”。对于value有些也可精简,比如性别使用0、1。

  2. 避免使用keys *
    keys *, 这个命令是阻塞的,即操作执行期间,其它任何命令在你的实例中都无法执行。当redis中key数据量小时到无所谓,数据量大就很糟糕了。所以我们应该避免去使用这个命令。可以去使用SCAN,来代替。

  3. 在存到Redis之前先把你的数据压缩下
    redis为每种数据类型都提供了两种内部编码方式,在不同的情况下redis会自动调整合适的编码方式。

  4. 设置 key 有效期
    我们应该尽可能的利用key有效期。比如一些临时数据(短信校验码),过了有效期Redis就会自动为你清除!

Redis--集群

  redis集群是一个无中心的分布式Redis存储架构,可以在多个节点之间进行数据共享,解决了Redis高可用、可扩展等问题。redis集群提供了以下两个好处:

  1. 将数据自动切分(split)到多个节点
  2. 当集群中的某一个节点故障时,redis还可以继续处理客户端的请求。
  3. 一个 Redis 集群包含 16384 个哈希槽(hash slot),数据库中的每个数据都属于这16384个哈希槽中的一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。集群中的每一个节点负责处理一部分哈希槽
  • 集群中的主从复制:
    集群中的每个节点都有1个至N个复制品,其中一个为主节点,其余的为从节点如果主节点下线了,集群就会把这个主节点的一个从节点设置为新的主节点,继续工作这样集群就不会因为一个主节点的下线而无法正常工作

  • 注意:
    如果某一个主节点和他所有的从节点都下线的话,redis集群就会停止工作了
    redis集群不保证数据的强一致性,在特定的情况下redis集群会丢失已经被执行过的写命令使用异步复制(asynchronous replication)是 Redis 集群可能会丢失写命令的其中一个原因,有时候由于网络原因,如果网络断开时间太长,redis集群就会启用新的主节点,之前发给主节点的数据就会丢失

当前网速较慢或者你使用的浏览器不支持博客特定功能,请尝试刷新或换用Chrome、Firefox等现代浏览器