Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景

lvs+keepalived部署jenkins2高可用，包括部署步骤，参考文档等等

markdown语法

以上这个结构体占用内存多少空间呢？也许你会说，这个简单，计算每个类型的大小，将它们相加就行了，以32为平台为例，int类型占4字节，char占用1字节，所以：4 + 3 + 4 = 11，那么这个结构体一共占用11字节空间。好吧，那么我们就用实践来证明是否正确，我们用sizeof运算符来求出这个结构体占用内存空间大小，sizeof(MemAlign)，出乎意料的是，结果居然为12？看来我们错了？

Redis Scan返回数据量大于Limit的Count原因分析 Redis所有的Key都存储在一个大字典中，与JAVA的HashMap类似，是一个一维数组二维链表的结构，key会按算法取模计算的值挂到一维数组对应的值的索引的链表下。如下图： scan指令返回的游标就是第一维数组的位置索引，limit参数表示需要遍历的索引数量，不考虑字典扩容缩容的话，遍历将直接按一维数组的下标进行遍历。遍历的结果可能多可能少，因为不是所有的索引位上都会挂接链表，索引位上挂的链表的元素数量也可能有多个。每次遍历会将limit数量的索引位上挂接的所有的链表元素进行模式匹配过滤一次性返回给客户端。 我这次遇到的问题，是我每次通过scan获取匹配元素进行处理，但是为了不影响集群的性能，所以限制每次处理的元素不超过1024个，每次scan的数量限制为256个，但是程序跑着却突破了1024的这个限制，我就很纳闷，为什么我每次只scan256个，竟然会突破1024这个数量的限制，打了断点查看，一次scan竟然scan出来了2100多个元素，而且这2100个元素都是在一个位置上的。这个场景理论上只会在数据量特别大的情况才能够出现。为了找原因，翻redis的文档并没有翻到点上，看scan命令的说明也没看出个所以然来，然后就翻翻书，在《Redis深度历险 核心原理与应用实践》这本书上翻到了自己能够理解的说明。

Redis4.0新特性(一)-Memory Command 原文地址：https://www.jianshu.com/p/cd2951fa45f4 Redis4.0版本增加了很多诱人的新特性，在redis精细化运营管理中都非常有用(猜想和antirez加入redislabs有很大关系)；此系列几篇水文主要介绍以下几个新特性的使用和效果。 Redis Memeory Command:详细分析内存使用情况，内存使用诊断，内存碎片回收； PSYNC2:解决failover和从实例重启不能部分同步；PSYNC3已经路上了； LazyFree: 再也不用怕big key的删除引起集群故障切换； LFU: 支持近似的LFU内存淘汰算法； Active Memory Defragmentation：内存碎片回收效果很好(实验阶段）； Modules: Redis成为更多的可能（觉得像mongo/mysql引入engine的阶段）； Memory Command简介 redis4.0引入新的命令memory, memory命令共有5个子命令； 让我们能更深入要了解redis内部的内存使用情况。 通过memory help命令，可以查看除memory doctor的其他4个子命令； 5个指令简介如下： MEMORY USAGE [SAMPLES ] -“Estimate memory usage of key” MEMORY STATS -“Show memory usage details” MEMORY PURGE -“Ask the allocator to release memory” MEMORY DOCTOR - “A better observability on the Redis memory usage.

源文地址：https://www.jianshu.com/p/e927e99e650d Redis4.0新特性(三)-Lazy Free Redis4.0新增了非常实用的lazy free特性，从根本上解决Big Key(主要指定元素较多集合类型Key)删除的风险。笔者在redis运维中也遇过几次Big Key删除带来可用性和性能故障。 本文分为以下几节说明redis lazy free： lazy free的定义 我们为什么需要lazy free lazy free的使用 lazy free的监控 lazy free实现的简单分析 lazy free的定义 lazy free可译为惰性删除或延迟释放；当删除键的时候,redis提供异步延时释放key内存的功能，把key释放操作放在bio(Background I/O)单独的子线程处理中，减少删除big key对redis主线程的阻塞。有效地避免删除big key带来的性能和可用性问题。 我们为什么需要lazy free Redis是single-thread程序(除少量的bio任务),当运行一个耗时较大的请求时，会导致所有请求排队等待redis不能响应其他请求，引起性能问题,甚至集群发生故障切换。 而redis删除大的集合键时，就属于这类比较耗时的请求。通过测试来看，删除一个100万个元素的集合键，耗时约1000ms左右。 以下测试，删除一个100万个字段的hash键，耗时1360ms；处理此DEL请求期间，其他请求完全被阻塞。 删除一个100万字段的hash键 127.0.0.1:6379> HLEN hlazykey (integer) 1000000 127.0.0.1:6379> del hlazykey (integer) 1 (1.36s) 127.0.0.1:6379> SLOWLOG get 1) 1) (integer) 0 2) (integer) 1501314385 3) (integer) 1360908 4) 1) "del" 2) "hlazykey" 5) "127.0.0.1:35595" 6) “" 测试估算，可参考；和硬件环境、Redis版本和负载等因素有关

Redis4.0新特性(二)-PSYNC2 Redis4.0新特性psync2(partial resynchronization version2)部分重新同步(partial resync)增加版本； 主要解决Redis运维管理过程中，从实例重启和主实例故障切换等场景带来的全量重新同步(full resync)问题。 什么是Redis部分重新同步psync redis部分重新同步：是指redis因某种原因引起复制中断后，从库重新同步时，只同步主实例的差异数据(写入指令），不进行bgsave复制整个RDB文件。 本文的名词规约： 部分重新同步：后文简称psync 全量重新同步：后文简称fullsync redis2.8第一版部分重新同步：后文简称psync1 redis4.0第二版本部分重新同步：后文简称psync2 在说明psync2功能前，先简单阐述redis2.8版本发布的psync1 Redis2.8 psync1解决什么问题 在psync1功能出现前，redis复制秒级中断，就会触发从实例进行fullsync。 每一次的fullsync，集群的性能和资源使用都可能带来抖动；如果redis所处的网络环境不稳定，那么fullsync的出步频率可能较高。 为解决此问题，redis2.8引入psync1, 有效地解决这种复制闪断，带来的影响。 redis的fullsync对业务而言，算是比较“重”的影响；对性能和可用性都有一定危险。 这里列举几个fullsync常见的影响： 1. master需运行bgsave,出现Fork，可能造成master达到毫秒或秒级的卡顿(latest_fork_usec)； 2. redis进程Fork导致Copy-On-Write内存使用消耗(后文简称COW)，最大能导致master进程内存使用量的消耗。 (eg RDB: 5213 MB of memory used by copy-on-write) 3. Redis Slave load RDB过程，会导致复制线程的client output buffer增长很大；增大Master进程内存消耗； 4. Redis保存RDB(不考虑disless replication),导致服务器磁盘IO和CPU(压缩)资源消耗 5. 发送数GB大小的RDB文件,会导致服务器网络出口爆增,如果千兆网卡服务器，期间会影响业务正常请求响应时间(以及其他连锁影响) psync1的基本实现 redis2.8为支持psync1，引入了replication backlog buffer(后文称：复制积压缓冲区）； 复制积压缓冲区是redis维护的固定长度缓冲队列(由参数repl-backlog-size设置，默认1MB)， master的写入命令在同步给slaves的同时，会在缓冲区中写入一份(master只有1个积压缓冲区，所有slaves共享）。 当redis复制中断后，slave会尝试采用psync, 上报原master runid + 当前已同步master的offset(复制偏移量，类似mysql的binlog file和position)； 如果runid与master的一致，且复制偏移量在master的复制积压缓冲区中还有(即offset >= min(backlog值)，master就认为部分重同步成功，不再进行全量同步。 部分重同步成功，master的日志显示如下： 30422:M 04 Aug 14:33:48.505 * Slave xxxxx:10005 asks for synchronization 30422:M 04 Aug 14:33:48.