前段时间有朋友问我：创业这几年对你改变最大的是什么？
我想了半天，说道：应该是思考的角度。

一. 关于离职

只要涉及到团队，员工离职就是一个永远逃避不了的问题。

创业这几年，不停的有人入职、离职，人与人之间的关系可以多快的建立起来，有可以多快的消失掉。

而作为团队的leader要做的，就是通过 感情、成长、利益、希望 各种方面，将这段关系维持的尽量长一点。

之前，我一直在想，中小型的公司，即使能够一直还不错的活着，最终影响员工选择离开的是什么？
当时我得出的结论是：生活

在深圳，即使以腾讯这个规模的体量，也无法确保员工的薪水能够在深圳买的起房子，而仅仅只是能够提供部分无息贷款的方式。
那么小公司呢？

我想到最后，只有一个方法，那就是小公司要自己成长到足够的体量，足以让核心的老员工们，最终能够达到足够的财务自由。

然而，现实远要比想象精彩。

我忘记了还有理想这回事。

最难挽留的离职，不是太累，也不是没前景，也不是薪水低，而是理想。

就像我当年离职创业一样，并不是任何加薪之类的方式可以挽留的了的。

其实慢慢的，当公司足够强壮的时候，即时是leader级别的人离职也渐渐不会对公司产生多大的影响了。

而我一直相信并且也一直在被验证的事情就是：

每一个离开的人，都在让这家公司变得更好 ...

一. 前言

2016年6月17日凌晨5点钟，我们完成了服务器端V3版本的重构，切换的过程十分平滑且没有对线上用户产生任何影响。

这也正式标志着，我们的游戏服务器进入了一个全新的阶段。

我们上一次的重构是在 2014年12月23日，现在看看，时间过的真快啊。

而熟悉我的人应该知道，我特意为上一次重构写过一篇《游戏服务器端架构升级之路》，其中详细的讲述了我们游戏服务器从农业时代跨越到工业时代的历程。

而这次V3版本的重构，我将其定义为第二次工业革命。也许它没有那么的强大和完美，但是他切实的解决了现存的大部分问题。

二. 背景

之前的文章已经说过，V2版本的服务器的几个优点：

1. 支持服务器代码热更新而不影响外网服务
2. 架构模式足够简单：push-pull

但是，其简单的架构也存在一些缺点：

1. 业务模块之间容易互相影响

   比如两个游戏玩法 A 和 B，内部使用的逻辑、存储服务器都完全不同，但是在worker层却是共用的。

   所以一旦玩法A的服务器出现问题导致处理变慢，那么worker就会被堵住，而玩法B也会跟着遭殃。

   同时，即时在一个业务模块内，也存在请求处理优先级的问题，比如拉取牌局记录和跟注，要尽量避免跟注这种核心逻辑受到影响。

2. 限制了游戏逻辑的实现方式

   V2的多worker的模式，导致worker必须限制为无状态的，因为worker可能处理任何一个请求，而一个请求也可能被分配到任何一个worker上。

   这一点是之前解决服务器热重启的关键，但同时也限制了我们代码逻辑多样性的实现。

   比如我们的游戏桌子数据是存储在redis中，所有人对桌子的写操作可能同时分配到多个worker上，而为了避免写冲突，我们不得不通过redis来实现分布式锁 ...

一. 部署自己的git服务器

之前一直是在用bitbucket来做代码托管，因为它的服务器在国外，所以客户端提交大文件的时候慢的跟蜗牛一样。而我们服务器是直接使用tag来进行部署，有时候代码拉不下来也非常痛苦。

正好这次bitbucket提示我们客户端代码已经超过1G，一旦超过2G就无法再push新代码，所以就狠心自己来搭建了。

代码肯定是用的gitlab，版本是7.9。一开始用的7.8，好像对中文支持有bug，后来又升级的。
8.x系列好像部署起来更简单些，也尝试了一下，感觉太傻瓜了导致各种配置路径都不知道在哪，所以还是决定使用7.9。

因为git本身的特性，迁移代码也没费多少力气。

小伙伴们用了新的git服务器之后，普遍反馈速度快的都不习惯了，哈哈。

其实之所以把这件事情单独拿出来说，是因为我觉得这个事情是有着超过其本身的意义的。
那就是：公司已经成长到可以投入一些成本到一些原本第三方能够解决的服务上了。

这其实是一个很大的进步，当公司处于生死边缘挣扎时，是不会去理会这种事情的。

同样的，我们的统计服务也越来越完善，而之前常用的友盟基本已经抛弃不看了。

二. 支持IPv6

我昨天在朋友圈发了个状态：

苹果说：要有光，于是世界有了光。

说实话，也只有苹果敢这么强势了。说是6月1号之后必须支持IPv6，我们版本6月2号就因为这个原因被打回。

而因为我们的网络底层是直接操作的原生socket，所以没法直接使用ios提供的封装库。不过这个最后还好，https://tools.ietf.org ...

之前在文章里面有提到过，很多事情，并没有绝对的对错，只是度的问题。而度的衡量又取决于时、势二字。所以当形势逼人的时候，基本就是这件事情非做不可的时候了。

先说下背景，公司的服务器一直用的阿里云，包括mysql、redis也都是买了ECS自己搭建的。这里面有几个原因:

1. 创业的时候，阿里云只提供mysql的存储，redis的存储还没提供。
2. 没钱，即时现在去看redis的存储价格也是贵的吓人。

这样自己来搞存储有好处也有坏处。 好处：

1. 完全可控，比如连接数限制，内存限制，存储限制。还有数据备份的灵活性等等。
2. 强迫团队服务器研发要有存储运维能力。
3. 省钱

坏处：

1. 冷备、热备方案不完善。
2. 存储运维的成本较高，需要长时间积累。

ok，问题就是这样，接下来再来说一下我们之前的冷备和热备方案。 可以说极其简陋：

1. mysql、redis每天10点冷备，备份到本地磁盘和阿里云OSS
2. redis使用rdb落地，每60秒至少有1次写就会触发落地。

这样做的问题其实挺多的，主要几个:

1. mysql dump的时候会导致游戏卡顿，即使加了 --single-transaction 参数 也仅仅是缓解
2. 冷备频率过低，真出现问题数据已经太久
3. 没有热备，风险较大

针对这些问题，我们先做了mysql备份的优化 ...

前段时间招聘服务器端研发，面到了一个人，忽然感想挺多，所以就写在这里。

这个同学怎么说呢？他自己可能感觉自己很有想法，很与众不同。
举几个例子：
比如，觉得他所在公司的一个框架的版本太低，官网都更新到v13了，他们还在用v7。想要推动公司内升级，他们技术老大又不肯。所以他觉得公司没有创新精神，死气沉沉。
又比如，研究过redis、mongodb或者其他一些开源框架，就觉得想要应用到公司内部来。但是推了半天又推不动。所以又开始觉得公司不够开放。
又比如，炫耀自己喜欢逛github、stackoverflow，还用rabbitmq写了一个分布式消息处理框架，但是问到承载量，性能瓶颈等等，又完全回答不上来。
又比如，我问了几个网络编程的细节问题，比如 epoll的水平和边缘触发、TIME_WAIT的原因与处理，结果一问三不知。

类似种种。

我之所以拿这个事情，单独写一篇文章来讨论，就是因为我知道，有一批人，一定会走到这个阶段。
因为现在的他，就是当年在腾讯时的自己。

当年的自己也是学了点python，用django写了个网站，逛了github，结果就像发现了新大陆一般，觉得自己牛逼了，别的同学都太out了，连python脚本都不会用，看，同样的功能，用python开发速度比c++快十倍！

所以当时公司很多的工具我都尝试用python来写 ...

其实一直想着写一篇2015年的总结，结果从过年回来就一直忙忙忙，拖到了现在。
本来今晚还想着继续做代码优化，突然听到外面下起雨来，就想着不如趁着今晚把文章给写了吧。

之于公司

15年对我、我的合伙人、乃至我们整个团队来说，都是充满意义的一年。

我记得在很久之前，别人是这样给我形容一家公司从不赚钱到赚钱的过程：

就是突然有一天，你看了看报表，发现，咦，我们盈利啦？！

而这一天，发生在了我们身上的时候，是2015年的10月的某一天。

那是我们奋斗近两年来，第一次看到曙光。

虽然其实盈亏也仅仅是基本打平，但是15年底，我们把我们能动用的所有钱，都拿出来给员工发了年终奖。

我和我的合伙人们，极其的感激这些在最困难的时候陪着我们，并且愿意跟我们一起继续走下去的战友们。

而同时，我也十分的想要告诉那些曾经因为各种原因离开了我们团队的人，感谢你们，让我们坚强并成长。

我最开心的是，技术团队目前还没有一个人在年后提出辞职，我也希望这些优秀的同学们能够一直陪着公司一起走下去。

2016年，已经过去了3个月了。
新的一年，我们得比以前更快！更拼！
2016，继续加油！！！

之于个人

15年对于我个人最大的喜事，应该就是媳妇怀孕啦！ 今天3月9日，马上就到预产期了，现在还有点忐忑自己会不会是一个好爸爸，哈哈。

其实我始终相信，肚子里的宝宝是个贵子，公司运营状况的好转，很大部分功劳都归功于他啦 ...