我不知道别人是否和我一样喜欢记录点东西，但是我知道我必须要记，因为年纪大了，如果不记录下来，很可能什么都忘了。
(伤心，我大约写了将近3000字的内容。没了，说实话，让我再写，可能写的没有刚才全了，希望我还能写点什么吧)
这次thinkingo的聚会对我来说真的是记忆犹新了。不谈路上堵车2小时吧，在高架上完全不能动，导航里写的只要半小时的路径走了2个小时。且谈好不容易写的心得吧。因为蓝牙鼠标左键失灵导致我以为是程序死了。让我重启了两次电脑 ，而明明sablog上面写的自动保存成功，却其实只保存了上文括号上面的那一句话。果然是老了。电脑也不帮我了
OK，让我再来一次吧，今天三个议题和一个话题
1、astaxie 的 go在cdn项目中的应用。
开始看到这个话题的时候，我还在想，今天是不是会话题重复了，毕竟七牛也是做云存储和CDN的，但后来发现asta讲的内容其实是内容分发这一块的，他们用go重新实现了内容分发模块，而原来则是用BT协议实现的。基于BT协议，有两个小问题：1.有1%的情况下，服务器节点只能从中心服务器取到99%的数据就卡死了。2.BT的搜索是无序的，不会优先从本地局域网进行下载，而是随机从任意节点下载，带来的问题就是机房的带宽反而被BT协议占用了不少，浪费了不少的流量费（现在的修改过的各种类BT协议，都调整过了，比如迅雷就宣称，会优先在局域网中下载从而避免流量占用过多）
asta他们则用go写了个分发协议，即中心服务器向节点发起通知，他们会先根据节点的机器数来进行数据块下载的分配 ，比如一个20个数据块，分散到节点的4台机器上则可能是1～5在第一台，6～10在第二台下载，以此类推，每个节点的机器下载完毕后通知中心服务器。这样中心服务器就知道哪些机器下载了哪些数据块。然后再通知第一台服务器从第二台上下载6～10，从第三台上下载11～15，以此类推。也就是说该节点的互联网流量其实就只消耗了整体数据的一次下载流量。而以前四台服务器，就下载完整的包四次，现在只有一次，其他的都是内网流量了。
这让他们不但节约了流量，还加快了速度
2、邵天宇 介绍了工作中对go的应用
邵天宇 他们公司是做微博方面的应用，这玩意大家都懂，其实能够从微博里挖掘数据都往往都是那些4A公司，现在也有越来越多的工司也开始慢慢在做这方面的工作，只有做的越多，才能越了解数据。gopher介绍他用go实现以前用python的功能后，CPU和内存的占用率都明显下降，性能更高。
邵天宇 介绍了几个他们公司用的一些用户分群的算法，细化到后面就是图的应用。
邵天宇 还介绍了他们使用的全文索引，说有个国内版的，整合了：Elasticsearch + IK，然后再加上leveldb来做处理，性能还算不错，原来是用wukong + sego，可是wukong的索引是存在内存里的，一旦机器重启就啥也没了。最后不得已才改用Elasticsearch + IK 。。（下次我也可以尝试一下）
3、七牛的韩拓介绍了下七牛中的GO使用情况
用韩拓的话来说，go的程序占据了他们的核心代码 的99%左右，但并不代表他们只用go来做所有的事，这可是一件蠢事，所以他们还是用了很多解决方案，比如lvs+nginx来解决高可用性的问题。用memcached来解决数据缓冲的问题等等
当然他介绍的最多的是他们日志系统，除了程序日志外，还有他们的事务日志。程序日志是他们的底层，事务日志是在程序日志的再一层包装。他们用日志系统包围了他们几乎所有的程序。即在程序的处理外层是被日志系统包围住的，日志系统就是一个蛋壳。它几乎充当了其他语言的try/catch，避免程序崩溃（这是我的理解，希望没有理解错）。虽然性能上有一点损失，但得到了更完整的日志，既可以分析系统，也能够用来当作收费依据。因此这些性能损失完全能够接受
----
话题中，韩拓提起了GC，引得大家一番热列的讨论。认为GC实在不可控。为了避免GC消耗大量的时间，每个人都有一些自己的看法，其实这个话题之前在知乎上已经有人讨论过：
- 先介绍下我的情况，我们团队的项目《仙侠道》在7月15号第一次接受玩家测试，这个项目的服务端完全用Go语言开发的，游戏数据都放在内存中由go 管理。
- 在上线测试后我对程序做了很多调优工作，最初是稳定性优先，所以先解决的是内存泄漏问题，主要靠memprof来定位问题，接着是进一步提高性能，主要靠cpuprof和自己做的一些统计信息来定位问题。
- 调优性能的过程中我从cpuprof的结果发现发现gc的scanblock调用占用的cpu竟然有40%多，于是我开始搞各种对象重用和尽量避免不必要的对象创建，效果显著，CPU占用降到了10%多。
- 但我还是挺不甘心的，想继续优化看看。网上找资料时看到GOGCTRACE这个环境变量可以开启gc调试信息的打印，于是我就在内网测试服开启了，每当go执行gc时就会打印一行信息，内容是gc执行时间和回收前后的对象数量变化。
- 我惊奇的发现一次gc要20多毫秒，我们服务器请求处理时间平均才33微秒，差了一个量级别呢。
- 于是我开始关心起gc执行时间这个数值，它到底是一个恒定值呢？还是更数据多少有关呢？
- 我带着疑问在外网玩家测试的服务器也开启了gc追踪，结果更让我冒冷汗了，gc执行时间竟然达到300多毫秒。go的gc是固定每两分钟执行一次，每次执行都是暂停整个程序的，300多毫秒应该足以导致可感受到的响应延迟。
300多毫秒，韩拓说他们遇到过是5秒左右，在线上运行的时候，gc停止了5秒左右。5秒对于我们来说没有什么，但对于一个做高可用的企业来说，已经是有点夸张了。
----
实在不想写了，很痛苦。之前写的全没了，就记录这么一点吧。(这次写的时候，居然又超时了，所幸我ctrl+s，保存了下来。天啊。。。我快崩溃了)