宕机Redis集群：单台宕机的应对方案
redis 集群技术能够有效地将数据分布到多台
服务器
上，从而提升性能、并发能力。但是在实际环境中，随着项目要求的增多、服务器硬件的消耗，单台服务器宕机的情况仍然是常态，因此必须要有一定的应对方案。
1. 配置高可用：Redis集群中每个节点都要被配置为同一VIP，这样可以让请求客户端将请求发送给VIP，而由VIP自己根据节点的状态转发给不同节点，在某个节点宕机时，另外一台节点可以处理。
2. 自动扩容：如果是一般的静态数据，那么可以配置一个定时任务，定期检查集群中节点的状态，如果发现某个节点已宕机，则启动自动扩容的脚本，在不影响业务的前提下，添加一台新的节点。
3. 节点数据迁移：在某些场景中，需要进行数据迁移，将某个节点上的数据迁移到其他节点，以维护数据的安全和一致性，具体实现有脚本等方式，或者利用redis 内置的SLAVEOF命令。
以上方法可以帮助我们在单台宕机的情况下，快速应对，不断提升数据的可用性。当然，要做好应急，其实还有其他的价值投入，如监控组件、日志记录等，可以帮助检测到单台宕机的情况，以及快速恢复节点，不断提升服务可用性和性能。
香港服务器首选树叶云，2H2G首月10元开通。树叶云（www.IDC.Net）提供简单好用，价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。
如何为Kafka集群选择合适的主题和分区数量
如何决定kafka集群中topic,partition的数量，这是许多kafka用户经常遇到的问题。 本文列举阐述几个重要的决定因素，以提供一些参考。 分区多吞吐量更高一个话题topic的各个分区partiton之间是并行的。 在producer和broker方面，写不同的分区是完全并行的。 因此一些昂贵的操作比如压缩，可以获得更多的资源，因为有多个进程。 在consumer方面，一个分区的数据可以由一个consumer线程在拉去数据。 分区多，并行的consumer（同一个消费组）也可以多。 因此通常，分区越多吞吐量越高。 基于吞吐量可以获得一个粗略的计算公式。 先测量得到在只有一个分区的情况下，Producer的吞吐量(P)和Consumer的吞吐量(C)。 那如果总的目标吞吐量是T的话，max(T/P,T/C)就是需要的最小分区数。 在单分区的情况下，Producer的吞吐量可以通过一些配置参数，比如bath的大小、副本的数量、压缩格式、ack类型来测得。 而Consumer的吞吐量通常取决于应用程序处理每一天消息逻辑。 这些都是需要切合实际测量。 随着时间推移数据量的增长可能会需要增加分区。 有一点需要注意的是，Producer者发布消息通过Key取哈希后映射分发到一个指定的分区，当分区数发生变化后，会带来key和分区映射关系发生变化。 可能某些应用程序依赖key和分区映射关系，映射关系变化了，程序就需要做相应的调整。 为了避免这种key和分区关系带来的应用程序修改。 所以在分区的时候尽量提前考虑，未来一年或两年的对分区数据量的要求。 除了吞吐量，还有一些其他的因素，在定分区的数目时是值得考虑的。 在某些情况下，太多的分区也可能会产生负面影响。 分区多需要的打开的文件句柄也多每个分区都映射到broker上的一个目录，每个log片段都会有两个文件（一个是索引文件，另一个是实际的数据文件）。 分区越多所需要的文件句柄也就越多，可以通过配置操作系统的参数增加打开文件句柄数。 分区多增加了不可用风险kafka支持主备复制，具备更高的可用性和持久性。 一个分区（partition）可以有多个副本，这些副本保存在不同的broker上。 每个分区的副本中都会有一个作为Leader。 当一个broker失败时，Leader在这台broker上的分区都会变得不可用，kafka会自动移除Leader，再其他副本中选一个作为新的Leader。 Producer和Consumer都只会与Leader相连。 一般情况下，当一个broker被正常关机时，controller主动地将Leader从正在关机的broker上移除。 移动一个Leader只需要几毫秒。 然当broker出现异常导致关机时，不可用会与分区数成正比。 假设一个boker上有2000个分区，每个分区有2个副本，那这样一个boker大约有1000个Leader，当boker异常宕机，会同时有1000个分区变得不可用。 假设恢复一个分区需要5ms，1000个分区就要5s。 分区越多，在broker异常宕机的情况，恢复所需时间会越长，不可用风险会增加。 分区多会增加点到点的延迟这个延迟需要体现在两个boker间主备数据同步。 在默认情况下，两个boker只有一个线程负责数据的复制。 根据经验，每个boker上的分区限制在100*b*r内（b指集群内boker的数量，r指副本数量）。 分区多会增加客户端的内存消耗kafka0.8.2后有个比较好的特色，新的Producer可以允许用户设置一个缓冲区，缓存一定量的数据。 当缓冲区数据到达设定量或者到时间，数据会从缓存区删除发往broker。 如果分区很多，每个分区都缓存一定量的数据量在缓冲区，很可能会占用大量的内存，甚至超过系统内存。 Consumer也存在同样的问题，会从每个分区拉一批数据回来，分区越多，所需内存也就越大。 根据经验，应该给每个分区分配至少几十KB的内存。 总结 在通常情况下，增加分区可以提供kafka集群的吞吐量。 然而，也应该意识到集群的总分区数或是单台服务器上的分区数过多，会增加不可用及延迟的风险。
HA是什么意思?
双机集群(HA)系统LATCH HA 是X0;linux Latch 系列的高可靠性的服务器集群系统解决方案。 今天各行业的顺利运转都依赖于计算机系统。 商品的订货、配送、客户服务、财务结算、保险及预约都需要高度可靠的信息服务系统。 这自然要求计算机的宕机时间越短越好。 LATCH HA能够自动检测系统的故障。 同时，一旦发现计算机出现故障，LATCH HA将把该计算机上的所有进程转移到备份计算机上，从而为客户提供不间断的服务。 一旦计算机宕机，LATCH HA能够将宕机时间缩短到几分钟甚至几秒钟。 而且能够将系统恢复到宕机以前的状态，从而保证计算机的稳定运行。 在LATCH HA的保护下，计算机系统再也不用因为硬件故障或日常性的维护而中断运行。 LATCH HA就是利用这些方法来提供最佳的服务可靠性，将计算机的宕机时间减少到最低程度。 要知道，一分钟的宕机时间也许会给银行，铁路，航空等行业的运营带来不可估量的损失。 还具有系统崩溃的智能检测与处理系统。 她利用各种手段来检测硬件、存储设备、网络及系统软件的故障。 同时，一旦发现计算机出现故障， LATCH HA将把该计算机上的所有进程转移到备份计算机上，从而为客户提供不间断的服务。 高可用性的实现的另一大关键就是的冗余策略，简言之就是对主机，网络设备，备份设备的多台备份（当然不只是简单的备份机）：LATCH HA拥有多种冗余模式，其中包括双机在线待机模式、双机就绪模式及三机模式。 所有的模式都提供了对各种备份资源－如文件系统、数据库、网络IP地址、系统进程、SCSI设备及NFS－的支持。 此外，高可用性的实现还要有丰富的应用程序支持: LATCH HA能够应用在各种集中式、客户机－服务器模式或OLTP系统中。 同时其与市场上各种主流的数据库系统与OLTP软件－如Oracle、 SYBASE、 Informix与Tuxedo－也都保持兼容。 LATCH HA同时提供了各种应用程序接口。 因此，客户能够在其私有软件中集成各种功能来保证系统的高可靠性，这样也保护了客户的投资。
发表评论