大多数应用开发人员(特别是php开发人员，不是我黑php orz)对锁可能都没什么概念，如果说有，那大概也只知道数据库 transaction
里的锁。即使是知道 db 的锁，了解也非常得粗浅(比如去年的我)。
实际上数据库的锁非常的复杂，和 os 的锁的概念完全不是一回事，具体实现还和存储引擎、事务的隔离级别相关。所以这里还是不谈这个orz。等我有机会总结了之后再说。
我们这里要说的是分布式锁。分布式锁是什么呢？
在分布式系统中，某个任务可能会因为正确性或者效率两方面的考量，在同一个时刻内只允许一个实例执行。
正确性
：例如有个游戏，每天凌晨0点，向所有玩家发放20金币的奖励，防止玩家输光了家当对游戏失去性趣。注意了，
以前在给开源项目贡献代码的时候，遇到过因为 golang 的 import path 导致的问题，详细可以参考这里
[http://xargin.com/egg-hurting-golang-import-problem/]。
由于 golang 本身没有像 java 或者 java 的儿子 javascript 那样集中式的包管理方式，例如 maven/gradle 或者即使是稀烂的
npm。便导致了 import path 里有各种网址开头的包。github.com/xxx/
最近和同事讨论了几句错误设计的问题，感觉有必要写写自己的看法。
举几个例子，一般你的系统在运行的时候可能会有下面这些种类的错误/失败发生：
> 依赖组件挂了，可能是 db，可能是 mq，可能是 cache
> 依赖服务挂了，可能是别人给你提供的 http/rpc 服务挂了
> 可能是你的依赖方超时了
> 可能是调用方的参数有问题
> 可能是调用方的参数无法正确地通过校验
> 可能是用户的某种操作在业务逻辑上不具有合理性，不能够接着让他执行下去(例如你就给他一天一次抽奖机会，他不知道从哪里拿来的链接或者api又向你发送请求
> 还可能是程序自身出错了，比如数组越界，对字符串和数字进行加和操作，或者是把 null 当成了某种合法的数据结构，通过点或者下标来获取某种属性
上面这些情况都是有很大概率发生的，当这种情况发生的时候，
某个群里因为消息队列和丢消息吵起来了，有人觉得 kafka 没有 ack，所以客户端缓冲会导致丢消息。
这理论有点牵强，即使真的丢消息也不会是因为客户端的缓冲问题。刚好之前仔细读过官方讲 Replication 的一篇 Kafka Replication 的
wiki，不是很长，但很详细地介绍了 Kafka 在做 producer ack 和 replication
的一些折衷。周末无事也就顺便翻译如下吧~以后查着也方便。
Kafka Replication High-level Design
为 kafka 加上副本是基于更强的持久性和高可用的考虑。
周末本来准备窝在家里打游戏，惊闻b站大佬要来北京分享，赶紧起床去听课。期间也和其它公司的人聊了聊，感觉收获不少。
B站现在作为国内二次元的门户，聚集了大部分的动漫爱好者，因为业务模型和日本的 niconico
比较像，所以早期也肯定从n站的产品上学到了不少东西(这句是我说的)。从文化衍生出的直播、周边、游戏服务又能够帮助这个站点进一步地造血赚钱，比如现在非常火的FGO。因为这一两年B站关注度变高，所以即使是对二次元没什么兴趣的人也会感觉和b站有关的新闻越来越多了。比如去年在知乎上先后有
flv.js、2233娘竞拍的事情，也是把他们推上了风口浪尖。
很多70后80后可能都不一定会上B站，但是你可能想不到B站也是一个亿级用户的站点了。从09年创立到现在，在技术上他们也经历了从一个创业公司到越来越正规的过程。有很多方面我觉得做得比现在的公司还要好。挑几个值得说的总结一下吧~
Code Review
首先是我来了现在的公司一直头痛的 Code
