阿里P8、P9及以上到底是什么水平？

P8，通常是一线Team leader或者二级域架构师，需要对一个领域的业务非常熟悉并且能够将影响力辐射到其他合作团队。一般来说一些业务架构、应用架构、产品功能决策、技术选型、协作分工等问题应该在P8层次终结。P8是一线作战的小队长，向下提供决策，向上提供有效的信息。

通常应届生P5入职，在6到10年可以达到这个层级（听说最快的P8是工作4年）。

P9，通常一般是一级域架构负责人（蚂蚁以前叫超域），二线团队负责人（也有部分一线直接带兵打仗）。这个层级已经可以影响到事业部的业务决策，是事业部的脑部力量，集团的腰部力量。

这个层级对于信息的过滤，判断以及基于信息的决策能力要求非常高。

通常P9不太会直接冲在一线做具体产品设计和系统分析工作，他们需要站在更高维度对部门和事业部的效率负责。

他们是重大业务架构和应用架构选型决策者，是向事业部负责人提供弹药的主要力量，也因此经常会沦为PPT供应商。

P9目前来看基本上是组织需要提拔，和能力挂钩但不直接联系起来，所以不是P8能力屌炸天就必须晋升P9。

成为P9，最重要的是能力、担当、业绩、全局视野，也需要机遇及向上管理能力，对于人的综合能力要求很强。

P9以上就可以进入集团组织部，那些基本上就不是个人主观希望努力达到或者不努力达到的事。

一、方案调研

1.1 redis版本选择

redis当前主流版本是redis 2.x 和 redis 3.x，3.0对集群支持比较不错，官方解释如下：

Redis是一个开源、基于C语言、基于内存亦可持久化的高性能NoSQL数据库，同时，它还提供了多种语言的API。近日，Redis 3.0在经过6个RC版本后，其正式版终于发布了。Redis 3.0的最重要特征是对Redis集群的支持，此外，该版本相对于2.8版本在性能、稳定性等方面都有了重大提高。

综合考虑之后扩展性和稳定性之后，选择版本 redis 3.2.3-1版本进行部署

1.2 是否选择搭建集群

是否搭建集群关键要看单机是否能够满足业务需求，做了个简单的数据评估。

数据量评估

• 测试：单机写入2000w业务数据，占用内存1.5g，本机126g内存

• 评估：单机的稳定数据承载量：2000w （126/1.56） 0.6 = 96923w

• 结论：9T 的数据承载量，远超当前千万级别的数据量

性能评估

• 测试：简单压测了下

• 写操作 1000w，80% 在20ms一下 ，98%在30ms，最大218ms，qps 5w/s，总耗时197s

• 读操作 1000w，97% 在10ms一下 ，99.99%在24ms，qps 6w/s，总耗时160s

• 评估：当前的调用量在千万每天，qps的话在百/s。

• 结论：当前单机的redis完全满足需求

因此：在单机远能够满足当下业务需求的情况下，决定不采用的集群的方式来部署redis，减少技术债务风险。

1.3 初定方案和架构图

选定了版本和基本部署方案之后，主要考虑服务的容灾和稳定性，经过思考之后采用采用极简的主从从结构，001实时同步数据002和003；001读写，002，003只读，机构图如下

二、实现过程

2.1 redis安装

此处略去，参考官方文档 https://redis.io/

2.2 配置读写master

• 修改端口：port 【目的：简单的修改默认端口是最好的防攻击】

• 添加密码：pwd

• 关闭压缩：rdbcompression no 【硬盘最够，降低cpu的能耗更利于提升性能】

• 开启守护进程：daemonize yes 【master开启守护，增加稳定性】

• 关闭protect-mode :允许他机器访问

• 添加白名单：bind xxx

• 修改log地址，pid地址和数据存储地址：logfile pidfile 【便于维护和安全】

• 添加慢查询：slowlog-log-slower-than 500 【根据业务需求，便于优化】

• 最大内存限制：maxmemory 【考虑稳定性和性能，一般不超过最大内存的60%】

• 具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加群。在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加群。如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的可以加群。java架构群：591240817 一起交流。
  

2.3 配置只读slave

• 同master

• 设置主库:slaveof ip:port

• 主库密码：masterauth masterpwd

• 只读：slave-read-only yes

2.4 启动测试

启动主库写入数据

进入从库查看

最初没有数据，主库写入之后，从库去到数据

查看log确认过程

三、架构能力评估

3.1 容灾能力

• 主动容灾

• 备份：master 全量备份，slave全量备份。

• 备份安全：本机保存，hadoop同步保存一份。

• 监控和探活：监控机分钟级探活和预警

• 被动容灾：

• slave 宕机：重启之后直接从master恢复

• master 宕机且硬盘数据为损坏：重启后数据自动恢复且和从库一致。

• master 宕机且数据损坏：删除损坏数据，使用slave1的数据恢复，保证数据一致。

• master 和slave 1 同时宕机：slave2 保证读正常，业务不影响，利用slave2 数据备份恢复master，启动slave 即可

• 三台全宕机：服务挂掉，从hadoop获取数据恢复服务。

3.2 性能评估

压测数据，参见方案选择，完全hold住。

四、问题思考

4.1 内存清理策略

暂时采用：

noeviction -> 谁也不删，直接在写操作时返回错误。

之后采用：

volatile-lru -> 根据LRU算法删除带有过期时间的key。 最少使用算法删除。

如果达到内存限制，手工清理，通过监控脚本监控内存情况

4.2 伸缩性和单节点问题

扩展slave可以直接扩展，扩展master需要master之间数据同步，暂时是个瓶颈。对于主读业务的需求，暂时问题不大；写需求的话，暂时的想法是代码转写的方式。

4.3 采用redis sentinal 监听

默认不错的监听，尝试了下效果不错，还在调研中，配置conf即可，完成后可以查看监听的情况

五：常用代码

# 强制杀死redis，模仿宕机

ps aux |grep redis |awk '{print $2}'|xargs kill -9

# 优化模拟宕机 【根据Dual-X-raY提示-_-】

redis> DEBUG SEGFAULT

# 重启，指定conf

/home/work/xxx/bin/redis-server /home/work/xxx/etc/redis.conf

# 压测，具体参数可以参考benchmark

[cuihuan@cuihuan bin]$ ./redis-benchmark -h 127.0.0.1 -p 端口 -a 密码 -c 1000 -n 10000000 -d 1024 -r 100000 -t set,get,incr,del