高可用架构在创刊的时候就订阅了，并且不止一次去云端下载，入 docker 也是因为当时看到了第一期《docker 实践》，可惜直到停刊的一年以后，才彻底和它划上句号。
你本质是懒，换个词就是 “拖延症是治不好的”。
《中国初创故事》：嗯，故事，不是传奇。（一年时间，9 个中的 3 个已死）
《硅谷篇》：人生苦短，天生骄傲，牛逼一些怎么了？
docker 实践
不一样的数据库
看完以后我真的噗嗤就笑了，黑的漂亮（数据库深度解析：从NoSQL的历史看未来）
可惜的是，如果大家了解科学发现的历史就会发现，自从爱因斯坦把牛顿那由完美数学保证的自洽理论踢出了神坛，数学自洽就再也不是真理的标准了。哪个的用户最多哪个就是真理。为什么关系模型最终赢得了比赛，而层次模型死掉了呢？很简单，因为人类都是蠢蛋和傻瓜啊。哪个简单易用，哪个就赢了。
Amdahl定律
我们深刻地知道，科学就是承认自己并非无所不能，然后不断地往那无所不能的地方努力的一种精神。
我们需要在那之前机器扩容，以及那之后要机器缩容，这些才是DRDS的核心能力
下次选择谨慎点，性能不是唯一，这次请节哀
你给我钱给我人，给我时间，我能用汇编写任何东西。
单表60亿记录等大数据场景的MySQL优化与运维之道
When the query cache helps, it can help a lot. When it hurts, it can hurt a lot. 明显前半句已经没有太大用处，在高并发下非常容易遇到瓶颈。
建议改成读已提交级别，可以满足大多数场景需求
mysql 进阶：
- 如果想成为数据库方面的专家，一定要挑选好环境，大平台很多时候会由于量变引发质变产生很多有挑战的问题，而解决这些问题是成为技术专家的必经之路。
- 首先，多读书，至少将《High Performance MySQL》英文版通读一遍。
- 其次，有条件的话，最好找一些大平台历练一下，在很多情况下经验和能力等同于你解决过的问题的广度和深度，而环境决定你遇到的问题。
- 最后，有机会的话多做一些技术分享，很多知识点自己明白和能给别人讲明白是两个完全不同的境界。
中国初创故事
- 会会：一个产品经理的创业方法论
可能还是做产品经理的时候，比较正确的做事方法论，让我有了较好的基础。
而到现在，产品除了考虑新的功能迭代之外，最重要的工作是从各种渠道搜集用户对于产品（以及同类产品）的反馈。
- 最右：如何打造90后亚文化产品
好产品是打磨出来的，花钱烧不出好产品，一拍脑袋的创意或者灵感一闪的想法也不能成就一个好产品。
- 拉拉公园：外企直男“跨界”Les社交
主要问题是花在扣技术细节的时间太多了。
后来坚持下来主要还是想要做出这个产品，在没有任何结果的时候放弃是最容易的。
我发现海外市场的垂直领域中，中国的应用开发者的勤奋和效率是很有竞争力的。
- 趣火星：文青创业能走多远
结果的落实也需要去跟进，落实的过程中偶尔会出现变慢或者是质量不好的时候。这时候需要有人站出来，如果大家都是和事佬这个事情就没得做了。
- 快法务：千万融资后唯一的奢侈是换了把椅子
技术的本质是工具
我们希望营造一种认同感，对彼此的认同，对事业和公司的认同。
心理预期的止损点
要得到家人的支持
自己得目标是什么一定要想清楚，
- 大食品：老记从“粮”千万融资背后的逻辑
做成一件事需要空气、土壤的配合，不可强求。
不经历挫折，总是缺乏成就大事的底蕴。
靠流量模式的电商，终会被以品质取胜的品质服务替代。
虽然一个人说了算的公司会更轻松，但有监管有结构的公司，促使创始人有更大的胸怀和格局。
一起去仰望星空。
- 嫁拍：不要温柔地走进那个良夜
细节重新定义“行业标准”
做一件让别人使用得满意的产品。
不要温柔地走入那个良夜。
可以去做任何让自己的梦想得以延伸的事情。
- 福佑卡车：在传统行业的潜规则中穿行
把大家聚集在一起，个人就肯定要舍弃一些东西。
做了十几年公司，经过这么多风风雨雨、起起伏伏，过程有时会很艰难，但我始终相信天道酬勤。
- 挑食火锅：什么才是外卖O2O竞争的正确姿势
然而真正的难点在于平衡
高可用架构·硅谷篇（第4期）
- Twitter高性能分布式日志系统架构解析
这种解决问题的思路叫做Pub/Sub。
数据需要持久化
数据复制到多台机器上
当数据被复制到多台机器上的时候，我们就需要保证数据的强一致性
持久化（durability）、多副本（replication）和强一致性（consistency）
定期回刷（periodic flush）
文件系统（pdflush）
日志系统的核心负载可以归为三类：writes，tailing reads和catch-up reads。
延时（latency）
Apache BookKeeper提供的三个核心特性：I/O分离、并行复制和容易理解的一致性模型。
所有的一致性的协调就是通过这个LAC指针（Last Add Confirmed）。
- 来自Google的高可用架构理念与实践
但是从3个9往上，就基本超出了人力的范畴，考验的是业务的自愈能力，架构的容灾、容错设计，灾备系统的完善等等
MTBF：Mean time between Failures
MTTR：Mean time to recover。
发布新版本，新功能是MTBF最大的敌人。
提高冗余度，多实例运行，用资源换可用性。
N+2应该是标配。
实例之间必须对等、独立。
流量控制能力非常重要。
Isolation。
Quarantine。
Query-of-death。
变更管理（Change Management）
线下测试（Offline Test）
灰度发布
服务必须对回滚提供支持
设计、开发时候就考虑好兼容性问题
把这个变更打回去，分成两半。第一半禁止访问这个数据。等到发布之后真没问题了，再来发布第二半，第二半真正删掉数据
开发一种跟版本无关的刷新机制
可用性7级图表
Crash with data corruption，destruction.
Crash with new data loss.
Crash without data loss.
No crash，but with no or very limited service，low service quality.
Partial or limited service，with good to medium service quality.
Failover with significant user visible delay，near full quality of service.
Failover with minimal to none user visible delay，near full quality of service.
自动化的SLA监控系统，能显示实时的SLA变化
扫雷比触雷要容易多了。
想要提高可用性，必须要和开发团队找到一个共同目标
error budget
每个机器上运行一个agent
- Uber容错设计与多机房容灾方案
non-sharded，stateless类型服务非常容易解决单点故障
TCP connect fail
receive timeout
sharding的方案：master, Consistent hashing
当设计一个服务的时候，它的throughput应该是可linear scale的。
有些RPC transport支持pipelining但不支持multiplexing（out of order responses）
event loop lag是指程序占用太长时间执行连续的CPU intensive任务
如果service实现了幂等操作也是可以retry
Uber数据抽象做的比较好，数据分为3类： 最小的realtime的 比较大非realtime的 最大非realtime的
http+json
tchannel+thrift
fail fast
可以针对一些用户关掉一些feature
- 关于工程师文化的思考
在办公环境/内部沟通这一块很不一样：
Memegen
每个人都有一个自己的主页
日历
组织汇报关系
公司内简历
会议
Testing On The Toilet
技术讨论/活动/培训/兴趣小组/内网新闻/邮件/邮件组
相对来说我比较看重的几个问题是：
工程师如何定位（怎么看待自己）？
工程师和产品、运营、销售等的关系？
谁/如何驱动公司前进？
领导是最自信的产品经理，好的产品奇缺
产品普遍更能受到工程师的尊重
产品的人员占比很低
产品的招聘门槛很高
产品的压力比较大
大家都做好自己
产品对技术的理解力
所以真心希望：
领导们能够管住自己的手
工程师掌握非技术的沟通
突破”技术思维”
技术人的定位更多应该是工程师，而不是程序员，更不能只是PHP程序员。
所有的这些问题几乎都可以通过“全公司统一代码仓库”+“主干开发”解决
只做一次，一次做好”有时候可能比单纯强调“敏捷”靠谱得多。
但是这世界上没有任何可持续的指数增长
全公司统一的招聘标准
多轮对等的面试来校验
对面试官的纪律要求和多轮的培训
对面试官的考核
资深面试官配合新面试官，相互印证
更资深的招聘委员会
- 给你介绍一个不一样的硅谷
最重要的问题是人生要有大目标，要有理想，要有情怀
人生苦短，天生骄傲，牛逼一些怎么了？
高可用架构·Learning as we Go（第5期）
- 用Go构建Teamwork Desk时犯下的菜鸟错误
约定优于配置
- 并发之痛：Thread，Goroutine，Actor
We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction.——Akka
线程（Thread）
另外也带来复杂度：竞态条件（race conditions）；依赖关系以及执行顺序
引入了许多复杂机制来保证：Mutex（Lock）（Go里的sync）；Semaphore；Volatile；Compare-and-swap
问题：系统里到底需要多少线程？内存（线程的栈空间）；调度成本（context-switch）；CPU使用率
方案：线程池方案；设置和CPU核数相等的线程数
陈力就列，不能者止
要做到这点一般有两种方案：异步回调方案；GreenThread/Coroutine/Fiber方案
几个概念：
Continuation
Coroutine是Continuation的一种实现
Fiber和Coroutine其实是一体两面的，可以理解成Coroutine运行之后的东西就是Fiber
Goroutine其实就是前面GreenThread系列解决方案的一种演进和实现
Actor模型
现实世界更像Actor的抽象，互相都是通过异步消息通信的
Actor有以下特征：Processing，Storage，Communication
Don't communicate by sharing memory, share memory by communicating.
Rust解决并发问题的思路是首先承认现实世界的资源总是有限的，想彻底避免资源共享是很难的，不试图完全避免资源共享，它认为并发的问题不在于资源共享，而在于错误的使用资源共享
革命尚未成功同志任需努力。
构想：在Goroutine上实现Actor？
分布式
和容器集群融合
自管理
- Golang并发编程总结
Golang的pool有以下解决方案：
sync.Pool
container/list
递归锁或者叫可重入锁（Recursive Lock）
锁等待超时机制
Map机制的问题
Golang的test -race参数非常好用
- 如何用Go实现支持数亿用户的长连消息系统
关于push系统对比与性能指标的讨论
单机的连接数指标
消息系统的内存使用量指标
每秒消息下发量
哪些因素决定推送系统的效果？
首先是sdk的完善程度
客户端对于数据心跳和读写超时设置，完善断线检测重连机制。
go语言开发问题与解决方案
- 散落在协程里的I/O，Buffer和对象不复用
- 网络环境不好引起激增
- 低效和开销大的rpc框架
- Gc时间过长
- Golang在视频直播平台的高性能实践
把大服务拆细，然后服务化独立部署，更容易简化部署，也容易单点细节优化与升级。多数服务的能力是通用的，如平滑重启、多机房部署等
- 杨武明：从3000元月薪码农到首席架构师
在《联盟》中，提供了一种使雇主与员工之间从商业交易转变为互惠关系的框架，创建了一种鼓励公司和个人相互投资的工作模式。
每个人对于价值观有不同的理解，我个人对于人生幸福理解很简单：年轻时有人生阅历丰富的人（下面我姑且称之为长者）指导，跟随有理想的长者去学习及改变世界；到自己成为长者时，也同样能将相同的价值观及做事方法影响一批人，聚拢一批有志青年来一起做有意义的事情。
决定自己将来也要打造出一支有技术范与战斗力，同时能服务于社会并带来商业价值的工程团队，同时实现财务自由。
高可用架构·高压下的演进（第6期）
唯品会RPC服务框架与容器化演进
服务化的原因：服务复杂度高；团队规模大；弹性应对高并发能力；足够的容错和自愈能力；降低维护成本
一般公司技术体系可以分成基础层、业务层、接入层三层的划分
服务注册与发现：原理上只要把服务注册到公共的地方，即把IP+端口注册，然后client端获取对应的IP+端口的列表就可以了
服务治理：尽量让所有的中心化功能都本地化；灰度流量控制
治理策略：减化运维；中间聚合层
RPC性能
整个服务化是一个体系
镜像的发布：Registry+Jenkins；Registry HA
网络：NAT的方式还是host方式；Linux VLan
资源共享：做一个限制的资源池的隔离
内存策略：默认的memory使用60%后就会使用swap，但是最好的方式尽可能用光memory再用swap
IO优化：两个IO比较关键，一个是磁盘IO，一个是网络IO；把不同的log文件用不同的磁盘隔离开；不是所有的应用程序所有的log都要输出；将log搜集到中心地方
建议最好用高性能万兆网卡和交换机
京东亿级商品详情页架构技术解密
商品详情页的架构：商品详情页系统；商品详情页动态服务系统和商品详情页统一服务系统；键值结构的异构数据集群
新的系统：数据变更还是通过MQ通知；数据异构Worker得到通知，然后按照一些维度进行数据存储；数据异构Worker存储成功后，会发送一个MQ给数据同步Worker；前端展示分为两个：商品详情页和商品介绍
MQ得到变更通知，Worker刷元数据到JIMDB，前端展示系统取数据渲染模板。
我们详情页架构设计的一些原则：
- 数据闭环
- 数据维度化
- 拆分系统
- Worker无状态化+任务化
- 异步化+并发化
- 多级缓存化
- 动态化
- 弹性化
- 降级开关
- 多机房多活
- 多种压测方案
一些总结
- 数据闭环
- 数据维度化
- 拆分系统
- Worker无状态化+任务化
- 异步化+并发化
- 多级缓存化
- 动态化
- 弹性化
- 降级开关
- 多机房多活
- 多种压测方案
- Nginx接入层线上灰度引流
- 接入层转发时只保留有用请求头
- 使用不需要cookie的无状态域名（如c.3.cn），减少入口带宽
- Nginx Proxy Cache只缓存有效数据，如托底数据不缓存
- 使用非阻塞锁应对local cache失效时突发请求到后端应用（lua-resty-lock/proxy_cache_lock）
- 使用Twemproxy减少Redis连接数
- 使用unix domain socket套接字减少本机TCP连接数
- 设置合理的超时时间（连接、读、写）
- 使用长连接减少内部服务的连接数
- 去数据库依赖（协调部门迁移数据库是很痛苦的，目前内部使用机房域名而不是ip），服务化
- 客户端同域连接限制，进行域名分区：c0.3.cn c1.3.cn，如果未来支持HTTP/2.0的话，就不再适用了。
小米抢购限流峰值系统架构历年演进历程
最初的抢购系统内部代号：TD。
限流服务，内部代号：TC。
Etsy架构现在成了什么样子？
想要雇佣伟大的牛人。你在哪才能找到伟大的牛人？如果你正在使用最新最热的技术，可能你很难发现这些牛人，而且价格也会更加昂贵。如果你使用的技术十分成熟，比如PHP，那么这件事就没有那么困难。
这是一种足够成熟而且被验证过的技术吗？
它会真正解决问题吗？它是解决问题的最佳方式吗？
这个组件和我们的组件在一起会有什么样的反应？
谁来支持这件事？
所有和这个实现相关的人员必须有“做什么，何时做，如何做”的计划。
我们非常看中我们网站的正常运行时间、可靠性，以及总体可操作性。
我们设置这些流程的目的主要就是为了确保我们只开源我们自己在生产过程中活跃使用的技术。
亿级短视频社交美拍架构实战
在美拍的服务化过程中，主要基于etcd来实现我们的动态服务发现和配置服务，在client层面扩展实现了包含负载均衡、心跳、节点健康状态探测、etcd节点挂掉的灾备等基础功能，同时会通过一些metrics埋点，以便跟踪内部的状态，用统一的trace_id来跟踪服务的链路调用情况。”——麦俊生
短视频所面临的架构问题：数据大小的差异；数据的格式标准差异；数据的处理需求
美拍遇到不少的挑战：性能的挑战；可用性的挑战；突发热点的挑战；业务频繁迭代的挑战
分而治之、化繁为简
开放扩展
分级隔离
资源冗余
容灾
雪球在股市风暴下的高可用架构改造
在快速迭代的创业公司，我们可能不会针对某一个服务做很完善的架构设计和代码实现，当出现各种问题时，也不会去追求极致的优化，而是以解决瓶颈问题为先。
在创业公司里，重写是不能接受的
我们现在正在所有的地方强推3个数据指标：qps，p99，error rate。
我们的原则：保持技术栈的一致性和简单性，有节制的尝试新技术，保持所有线上服务依赖的技术可控
遗留系统的优化，最佳方案就是砍需求，呵呵。
技术方案：20倍设计，10倍实现，3倍部署；扩展性：凡事留一线，以后好相见。
技术实现：DevOps：上线后还是你自己维护的项目，实现的时候记得考虑各种出错的处理；用户投诉的时候需要你去解释，实现的时候注意各种边界和异常；快速实现，不是“随便实现”，万一火了呢：性能，方便扩容
如何设计现代高速缓存
逐出策略
LRU
过期策略
苏武：蘑菇街架构的演进和我的成长
知识广度变广了，也有机会去了解和思考怎么去做事情
看到了很多做得好的和做得不好的地方。
架构其实很重要的一点是需要做权衡。
在沟通这一块
第一个项目给了我机会去解决问题，跟着问题跑的能力。第二个项目给了我更深层次的思考，改变了跟着问题跑的思考方式，做事情有了前瞻性。
我们做了一些比较简单的改进：业务垂直拆分；交易和支付DB和Cache独立；使用更好的硬件
开关平台
限流降级系统
架构设计上如何为未来留有余地：技术产品的准备；业务平台的沉淀；架构梳理
系统容量评估
线上的全链路压测
有损服务
限流
前后端分离
我们推崇做人简单、开放。做事以技术和数据说话。
我个人觉得是解决问题的能力和学习能力。
