使用的资源： nginx主服务器一台，nginx备服务器一台，使用keepalived进行宕机切换。 tomcat服务器两台，由nginx进行反向代理和负载均衡，此处可搭建服务器集群。 redis服务器一台，用于session的分离共享。 nginx主服务器：192.168.50.133 nginx备服务器：192.168.50.135 tomcat项目服务器1:192.168.50.137 tomcat项目服务器2:192.168.50.139 redis服务器：192.168.50.140 注意访问时需
redis作为内存数据库，为了防止因为程序bug或者机器故障导致的数据丢失，redis采取了多维度的措施来保障redis写入数据的安全。从单机层面：采取备份磁盘镜像+数据流水的形式，将内存状态落地到本地磁盘，防止因程序bug或者系统故障导致的数据丢失；从多机层面：通过主备机制，进行远程热备，保障数据安全。
前段时间记录了下 Redis 持久化的内容 回顾 。现在聊下 Redis 的主从复制，简单点的有一主一从、一主二从的配置，复杂点的例如哨兵模式。今天先从简单的入手，以一主二备配置来说，哨兵模式后续再补充。
假设主机ip：10.136.16.146 port：6789 备机ip：10.136.30.144
wget http://redis.googlecode.com/files/redis-2.4.2.tar.gz
昵称：院长 性别：男 爱好：羽毛球，乒乓球，嗨歌，钻研技术 技能：在下方 职位：落魄技术
摘要：作为noSql中的kv数据库的王者，redis以其高性能，低时延，丰富的数据结构备受开发者青睐，但是由于redis在水平伸缩性上受限，如何做到能够水平扩容，同时对业务无侵入性是很多使用redis的开发人员都会面临的问题，而redis分布式解决方案的一个开源产品【codis】较好的弥补了这一弱势，本文主要讲解codis是如何做到对业务无感知，平滑迁移，迁移性能高，迁移异常处理，高可用以及常见的redis的避坑指南，虽然codis目前随着公司的nosql产品越来越成熟，生命周期也即将结束，不过鉴于还
不知不觉，分布式数据存储这一站已经到了最后一讲。在前面几讲，我与你分享了 CAP 理论（想要设计一个好的分布式系统，必须搞定这个理论）、（分布式存储系统三要素，掌握这些就离成功不远了）、数据分布式分片方法和数据复制技术（分布式数据复制技术，今天就教你真正分身术），其中数据分片方法和数据复制技术均是导购中的关键技术。
首先，要有一个主备集群。假设有3台电脑分别是MASTER、SLAVE1、SLAVE2。分别在这3台电脑上安装好Redis，并在SLAVE1、SLAVE2上设置为从MASTER同步（replicaof ***），那么它们就组成了主备集群，但是如果主节点出现故障了，从节点并不能提升为主节点，依然不能写入。为了解决这个问题，就要用到哨兵了。
RDB会丢失最后一次备份的rdb文件，但是其实也无所谓，其实也可以忽略不计，毕竟是缓存，丢了就丢了，但是如果追求数据的完整性，那就的考虑使用AOF了。 AOF特点
考虑如何用 redis 来加多台机器，保证 redis 是高并发的，如何让 redis 保证自己不是挂掉以后就直接死掉了，即 redis 高可用？
随着企业对数据处理和存储需求的不断增长，Redis作为一款高性能的内存数据结构存储系统，已成为业界的首选。然而，在Redis中的使用中，会面对一些潜在的故障风险，其中主节点故障，发生主从切换最为常见。
前几天看到某大型家电工厂的工业互联网系统架构图，发现用MongoDB存储图片及视频。那Redis同样也是Json类型的远程数据字典服务器，也可以用于存储图片、视频。实际Redis可以用512MB的空间存储用于存储字符串型的数据。
为了应对地震、火灾等不可抗力导致本地备份数据丢失的情况，业界提出了异地灾备的技术理念。CPDR （Control Plane Disaster Recovery，控制平面灾备）是一种应用在vBRAS转发与控制分离组网中的异地 灾备技术。它通过在两个分属于不同DC（Data Center，数据中心）的CP之间进行双机备份来实现异地灾备， 从而达到当一个DC发生灾难时，由另一个DC快速接管用户业务的目的。
当我们搭建集群的时候,首先要想明白需要解决哪些问题,搞清楚这个之前,想想单节点、单实例、单机有哪些问题? 单点故障 容量有限 可支持的连接有限(性能不足) ...... 为了解决这些问题,我们需要对服
z轴：优先级、逻辑再拆分。比如说某个模块数据过多，可以拆分为多个Redis客户端，全量数据分为多份，每个Redis中存一部分数据。
交换机的类型，direct、topic、fanout、headers，durability（是否需要持久化true需要）auto delete当最后一个绑定Exchange上的队列被删除Exchange也删除。
腾讯云网络自研路由平台—FCR 云网络厂商在用户接入侧一般采用传统网络设备如路由器、交换机，传统网络设备虽然功能稳定，但是开发周期较长，支持功能无法快速匹配互联网厂商日新月异的应用场景。为了解决上述问题，腾讯云网络在接入时使用了FCR（Fast Cloud Router）作为自己的路由控制平台。 FCR自研路由平台不仅支持BGP、静态路由、BFD等各类路由相关协议，同时还可以提供丰富的路由策略以及百万级的路由管理功能。 平台开放：完全基于开源组件构建，打破了传统设备厂商封闭的产品生
版本： redis-3.2.9 部署： 5台64G内存的物理机，每台机器启动2个redis进程组成5主5备集群，每台机器1个主1个备，并且错开互备。 问题： 发现redis进程占用内存高达40G，而且全是备进程。尝试通过重启进程方式释放内存，但进入复制死循环，报如下所示错误： for lack of backlog (Slave request was: 51875158284) 通过网上查找资料，修改client-output-buffer-limit和repl-timeout值，问题未能得到解决，仍然报for lack of backlog，并仍然循环复制。 move备进程的data目录，但保留nodes.conf文件，然后再重启，这次重启成功。采取同样方法处理其它备进程，同样成功，内存同样降到和主进程接近的大小10G。 待分析：为何备进程占用的内存是它的主进程的4倍（分别40G和10G）？除了上述方法外，是否有其它更安全可靠的释放办法？
前言： 本文在书写之前，拜读了张开涛：《亿级流量网站架构核心技术》一书，该书写的系统性很强，建议购买阅读。 本文仅代表个人观点。 本文通过一张图，将分布式开源技术的知识点串起来，方便整体了解和查阅。
RabbitMQ是基于AMQP协议的，通过使用通用协议就可以做到在不同语言之间传递
RabbitMQ是基于AMQP协议的，通过使用通用协议就可以做到在不同语言之间传递。
派大星：Redis的高可用架构，叫做failover故障转移，也可以叫主备切换。master node在故障时，自动检测并将某个slave node自动切换为master node的过程，叫做主备切换，这个过程，实现了Redis的主从架构下的高可以用。还有一种是Redis基于哨兵的高可用性。
之前在中通负责过缓存平台的建设工作，当时的缓存系统使用搜狐 TV 开源的 CacheCloud 缓存服务平台进行托管，但随着公司业务发展，随着而来的是资源隔离、集群访问权限粒度、资源不均衡、仅支持 Redis 类型的集群等问题，为了解决公司当下使用缓存的痛点，当时决定构建下一代缓存服务平台，它是基于 Kubernetes Operator 自动化部署与运维的思想，当时还写下了一篇文章：「中通缓存服务平台基于 Kubernetes Operator 的服务化实践」。
当数据落在不同节点上时，如何保证数据节点之间的一致性是非常关键的 Redis采用主备复制的方式保证一致性，所有节点中，只有一个节点为主节点（master），它对外提供写服务，然后异步的将数据复制到其他节点上
唐聪，腾讯云资深工程师，极客时间专栏《etcd实战课》作者，etcd活跃贡献者，主要负责腾讯云大规模K8s/etcd平台、有状态服务容器化、在离线混部等产品研发设计工作。 背景 随着 Kubernetes 成为云原生的最热门的解决方案，越来越多的传统服务从虚拟机、物理机迁移到 Kubernetes，各云厂商如腾讯自研上云也主推业务通过Kubernetes来部署服务，享受 Kubernetes 带来的弹性扩缩容、高可用、自动化调度、多平台支持等益处。然而，目前大部分基于 Kubernetes 的部署的服务都是
本来准备一天搞定一个redis的监控，能够查询相关的slowlog，能够看出内存的使用率，能看出主备情况，将所有的数据存储在redis中，然后再试试自动化创建redis主备，然而，并没有发现一天能搞定。。。FUCK
受网络和运行环境影响，应用程序可能遇到暂时性故障，如瞬时网络抖动、服务暂时不可用、服务繁忙导致超时等。
在memcached的解决方式中。分布的不同memcached结点彼此是不能通信的，要实现memcached结点的之间的Master/Slave结构。有一个日本同学开发了一个第三方的工具Recached，能够实现Memcached的主备结构。从结点能够实时的同步主结点的数据，当主节点挂掉，从结点能够热备的提供服务。
服务端：codis-fe------codis-dashboard------codis-proxy------codis-group------codis-server
在使用数据库时，表的主键经常会使用数据库的自增（auto_increment）来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方，也就是发号器来产生全局唯一 ID，这些问题就可以得到解决，生活就可以更美好。
Redis的性能很好，但在某些情况下还是不能满足我们的需求，比如过多的用户进入主页，导致Redis被频繁访问，此时就存在大量的读操作。在一些秒杀场景中，一瞬间有成千上万的读请求到达Redis服务器，显然单靠一台Redis服务器是不够的。一些服务网站对安全性有较高的要求，当主服务器不能工作的时候，需要从服务器代替原来的主服务器，作为灾备，以保证系统可以正常运行。因此更多的时候我们希望读写分离，读写分离的前提是读操作远远比写操作频繁的多，如果把数据存放在多台服务器上那么就可以从多台服务器上读取数据，从而消除了单台服务器的压力，读写分离的技术已经广泛用于数据库中。
集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。
这次我们讲讲redis的一些配置要点，包括日志，持久化，主备，数据压缩，内存分配等，以及一些坑，简单的配置就不说了，可以去看官方文档。
尽管 Redis 的性能很好，但是有时候依旧满足不了应用的需要，比如过多的用户进入主页，导致 Redis 被频繁访问，此时就存在大量的读操作。显然单靠一台 Redis 服务器是完全不够用的 当主服务器不能正常工作的时候，我们希望从服务器代替原来的主服务器，作为灾备，以保证系统可以继续正常的工作 。
Redis 频繁进行主备倒换，通过查看主实例的日志：redis.log发现下面报错：
随着客户上云的加快，客户越来越希望直接采用云上的数据库系统支撑业务发展，作为服务商来讲，了解云上的数据库的应用场景及常见特性成为必然。否则，将出现与客户交流困难，影响项目成效的麻烦事。今天我们讲五种常见的云数据库，这些内容也是在与客户沟通交流中的常见问题。
《【面试突击】— Redis篇》--Redis的线程模型了解吗？为啥单线程效率还这么高？
并发量大了 =》 主从复制解决 =》主从稳定性 =》哨兵解决 =》单节点的写能力、存储能力、动态扩容都很麻烦 =》集群Cluster解决。
当主从的redis性能和容量满足不了项目的需求时，一般会采用集群方案。而原生的集群方案是一个比较好的选择。本文主要是讨论如何保证集群版高可用。高可用分为选择最佳的机器、修复节点故障、升级或者修复软件故障、让数据落地保存这几个方面。
什么是热点问题？在我们生活中，定义是：比较受广大群众关注或者欢迎的新闻或者信息或指某时期引人注目的地方或问题。
来源：https://blog.dogchao.cn/?p=299 前言 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过 F5 或者任何代理
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里
点击上方蓝色“程序猿DD”，选择“设为星标” 回复“资源”获取独家整理的学习资料！ 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存，比如MySQL数据库，redis等内存数据库。除了这两种类型的维护方式，还有jvm的内存的状态维持，但jvm的状态生命周期通常很短。 高可用的一些解决方案 高可用，从发展来看，大致经过了这几个
在上一篇通知文章有说过，六月份会开始更新公众号，虽然现在已到月底了，但好歹也算没有失言，赶上了末班车了。
在日常开发中会经常遇到一些需要异步定时执行的业务诉求，典型的使用场景如：超时未支付订单关单、每隔 2h 更新好友排行榜、3.22 日 17 点《xx》剧上线等。目前业务侧多基于以下思路来快速搭建一个调度系统，mysql 或者 redis 队列存储待执行任务，通过 crontab 定时触发应用完成“捞取、计算、执行等操作”。不难看出存在几类亟待解决问题：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
