为什么要整理一下Linux下的打包和压缩工具呢？原因很简单，因为遇到问题了：游戏服务器可执行文件、配置和各种资源文件有4G多，每次在做版本的时候，编译完打包压缩要用掉10分钟多。我在上篇C++构建系统选择里面有提到过，200万行的代码编译用时不到10分钟，而现在一个简单的打包压缩竟然占用了10分钟，虽说这个步骤日常开发过程中很少操作，但每次凌晨做版本的时候，由于需求的变更，需要不断地构建、打包、压缩。做版本的同学苦不堪言，所有开发人员也得等着，这样浪费大家宝贵的时间是极度可耻的！遇到问题就要解决问题，问题解决了如果不记下来，下次遇到了又得去折腾了。下面进入正题。
虽说打包和压缩的原因各种各样，最重要的目的就是：减少文件的体积，从而节约磁盘空间和网络带宽。压缩文件的时候，最注重两个因素：速度和压缩比。慢如蜗牛还是快如闪电？当然选择越快越好、压缩比越高越好。但是鱼与熊掌不可兼得，往往压缩比高的算法，需要的计算量就比较大，花费的时间就比较多。有没有加速的办法呢？
下面我会介绍一下我所熟知的Linux下的打包压缩工具，并做下对比，给出建议。上面遇到的问题，最后也会给出解决方法。
C++少说也用了十年了，从简单的Hello World到200万行的游戏项目，编译和构建的工具也经历了各种升级。最终的开发环境，选择了Clang+GDB+CMake。当然不断改进和升级开发工具的脚步尚未停止，只要能提高开发效率，怎样折腾都是值得的。
期间经历了：
一直在寻找好用的写作工具或平台，来来回回折腾从未休止。从CSDN、CNBLOGS的博客平台、自己建空间申请域名使用WordPress写技术文章，直到现在使用静态博客生成工具Jekyll+Markdown+Github。从07年开始到现在，中断了不少，因为各种原因就是无法坚持下去，没有一个好的平台和工具也是其中一个原因。
文章托管在别人的博客平台上，好处就是一方面比较安全，不怕个人电脑出问题，另一方面是这些平台基本上会有相应的社区，写的文章被别人看到的几率会比较大。但是，这些博客平台都是在线编辑，在一个丑陋不堪的网页编辑框里面，小心翼翼地调整着格式，同时还要担心不要一不小心踢掉电源或者网线，刚刚写下的内容丢失（这样的事情曾经遇到过好几次）。最大的问题是，提供的编辑器多数都是半吊子，语法高亮、数学公式这些元素都不一定支持，纷繁的HTML格式总是让人有点抓狂的感觉，被这些形式的东西虐个几次之后，那里还有什么心思静下来写作。
继上周陆续发布了一些防外挂的措施后，打金工作室（英文叫：Gold Farmer，真是太形象了）仅用了一天左右的时间就破解了客户端的通信秘钥生成算法，这个速度完全有点出乎我的意料，当然我也仅仅是猜测，工作室使用的是脱机外挂，否则很难同时登陆上万客户端，需要大量的硬件资源才可以做到。最近一段时间，打金工作室外挂集中在新开游戏服里面，大量创建角色并且登录游戏进行打金，有些游戏服外挂达到2W多，而正常用户仅有3-4K左右，同时进行操作时，对游戏服务器造成巨大压力，严重影响正常用户的游戏体验。本周在服务器端做了一些处理，效率有所好转，还有一点不理想的地方，下周还需进一步优化。
快到节假日的时候，总有那么一群人在苦逼加班中度过。运气好点的，节假日也可以顺顺利利地过了，运气差点的，节假日也别想过的安生。当很多人国庆节在外面旅游晒照的时候，我等却在担惊受怕地听候差遣。也真是奇了怪了，现在这个节日还真多，互联网行业莫名其妙弄出个双十一，后面又出来个双十二。每次遇到这两个互联网购物狂欢节的时候。你或是在电脑旁边守候到零点疯狂抢购，抱怨网络太卡，网银无法支付的时候，咒骂这该死的某宝或某东的时候，我却想到的是这些服务后台那些苦逼的程序猿和运维的同学，目不转睛地盯着屏幕，心中在默默祈祷不要出问题。哎，又该是一个不眠之夜了。
我们做游戏后台的也好不到那里去，节日总是要开发点线上活动，拉拉收益的，何况是这些购物狂欢节呢。这不，国庆刚休假结束，有些同学还没缓过神来，又是一大波需求来袭，需要在短短两周内开发完成，说是什么周年庆。好吧，看来下面几个月都别想有好日子过了，加班是逃不掉的了。周年庆、双十一、双十二、圣诞节、元旦、春节。My Fucking God，怎么这么多节日啊！
大家节日欢乐无限，我等码农只能唏嘘不已，默默跪拜图灵大神。
我们同时维护着多个游戏项目，游戏内容大同小异，程序和策划基本上也是同一批人，难免一些功能，在A项目中开发完运行稳定，策划感觉效果不错，就要求把该功能迁移到B项目中去。于是，代码移植就在我们这里经常发生了，随着时间各个项目之间的差异越来越大，代码移植往往就没有策划想象的那么简单了。程序需要抽丝剥茧，小心翼翼地把代码复制来复制去，稍有遗漏就会出问题。
特别的，当策划同学在提出移植的时候，总是以为这是很简单的事情：“之前都不是已经实现了吗？照着抄不就完了？一天时间搞定如何？”。这时，心里真是一万匹草泥马在奔腾的感觉，在对功能需求不明确，时间有限的前提下来干这样一件事，这是让我们程序玩火自焚啊！
周三晚上加班到周四凌晨三点多，差两个小时就可以看日出了。一直处于无事等待状态，这样算是幸运的了。若这个时候有代码修改，那估计日出看定了。
加班本该是赶进度的一种手段，偶尔为之也是可以理解的。天天加班都不说什么了，每周版本发布前夕非要搞到大家一起看日出，这样好吗？策划同学貌似零点过后状态奇佳，灵感一个接一个，测试同学不紧不慢地测着，相关程序则必须守着，多数时候，程序呆在哪里什么事情都没有，纯粹就是为了其他人安心而已。
整天和计算机打交道的人，如果一直用手工去做一些重复的事情，那么你就是在犯罪。如果说时间就是生命，那么重复就是在挥霍自己的生命，同时也在浪费别人的生命，因为当你手工低效率做事的时候，别人也在等着你。
程序员的世界，最讨厌的就是重复，重复的事情应该交给机器来帮你完成，而并非同样的事情手动敲了一遍又一遍。人脑最擅长的是通过思考总结、分析、抽象出模式，而机器最擅长的就是重复。机器执行重复的事情，准确性和效率要完胜手工。机器做重复的事情，当然是通过编程来实现，包括：脚本，宏，使用自己或别人开发的各种工具等。要做一个比较懒的程序员，学会使用工具和脚本，现有的工具不能满足你的要求，那么就需要自己挽起袖子自己造一个了。把重复的事情交给机器来做，你要做的就是分析抽象出重复的模式，然后将它转化成工具。
事不过三，事不过三，事不过三！再重要的事情最多也只能说三遍，再说估计打我的心都有了！
刚接触MongoDB，就要用到它的集群，只能硬着头皮短时间去看文档和尝试自行搭建。迁移历史数据更是让人恼火，近100G的数据文件，导入、清理垃圾数据执行的速度蜗牛一样的慢。趁着这个时间，把这几天关于Mongod集群相关的内容整理一下。大概介绍一下MongoDB集群的几种方式：Master-Slave、Relica Set、Sharding，并做简单的演示。
使用集群的目的就是提高可用性。高可用性H.A.（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。
HA的三种工作方式：
主从方式 （非对称方式）
工作原理：主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
双机双工方式（互备互援）
工作原理：两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
集群工作方式（多服务器互备方式）
工作原理：多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管
直觉（英语：Intuition），又称为直观，通常被描述为，一种不用经过太多思考过程，很快就能出现的直接想法、感觉、信念或者偏好。当我们有某种信仰，但是不确知它的原因时，通常会将它归于是一种直觉。认知科学认为这是因为生存的演化压力而产生的人类心智能力，让人类可以快速做出判断，采取行动，它通常与右脑连结在一起。心理学与超自然学对这个能力深感兴趣。(以上内容来自维基百科)
有很多次，在我向新人演示或者帮助Ta解决宕机或BUG的时候，他们都会用诧异的眼神看着我，一脸疑惑地问道：“这么快地定位到问题，你是怎么做到的？”，然后我很装逼地对Ta说：“直觉”。当然，相视一笑之后，我还是会整理一下思路，然后解释一下推理过程。
可以快速解决问题的直觉，并非朝夕之间就能获得的。至今做了七年服务器端开发，遇到过各种各样的宕机和BUG，凌晨三四点被叫到公司家常便饭，也就仅仅获得了针对我们游戏服务器出的问题的一些直觉而已，多数时候还是挺准的。每次当我遇到一些疑难问题的时候，我心里都会默默在念：Every thing happened has a reason。事出必有因，现在没有找到原因，只是因为对问题的认识和分析还不够，考虑的还不够全面，应该分析所有可能的已知因素。就这样，你必须熟练并理解手头的各种工具和代码。正所谓熟能生巧，见得多了，理解的深了，在别人看来很难的问题也不是问题了，这是一个持久的过程，需要大量的时间和机会，当然征服问题的信念也是很有必要的。
当一个BUG/宕机出现的时候：
首先要弄清楚问题，要了解正常的代码逻辑，若是中途接手别人的代码，那就得硬着头皮去理解别人的代码。
然后，思考问题出现的环节，然后针对出问题的环节仔细分析代码的每个分支，往往一些很难复现的BUG很容易在分析代码的过程中发现。
最后要想到的才是复现BUG并使用调试工具进行追踪调试。
PS. 记得之前在笔试阅卷的时候，看到一个关于调试器的回答，问题是：“请写下你的调试工具及其简单用法？”，有一个同学的回答：“脑子”。开始拿来当笑话，笑过之余，想一下还是挺有道理的，脑子才是最牛逼的调试器，可以进行情景模拟，还原问题发生的各种可能性，请问GDB可以吗？哈哈。