Submitted by gouki on 2013, September 20, 9:46 AM
收到这封邮件的时候，心都碎了。
|
MAC PARALLELS DESKTOP 7 用户紧急服务通知： 如果您打算升级到即将发布的Mac OS X Mavericks （10.9），请注意Parallels Desktop 7将不支持Mac OS X Mavericks（10.9）。您将无法启动您的Windows虚拟机，或者在Parallels Desktop 7上直接使用您的文件。 在您安装OS X Mavericks之前；请升级到Mac的Parallels Desktop 9，因为它是现今唯一可用于Mavericks的版本。 |
心真的是哇凉哇凉的呀
Submitted by gouki on 2013, September 16, 2:44 PM
重启apache的时候报错：
Submitted by gouki on 2013, September 15, 9:10 PM
关于think2go的介绍，我自己是写了一篇，但因为第一次写的内容不慎消失，后面是重写的。心情和精力都不佳了。
首先是谢大闪亮登场，为我们分享他用Go语言在盛大的CDN系统中的应用，大家鼓掌。
我觉得讲的主要内容上可以分两大块来看，一部分是从中心结点到IDC的文件分发过程，另一部分是用户请求到达之后的调度设计。
主要应用场景像什么游戏客户端的分发之类的。先说中心结点服务器到IDC服务器的分发过程。
谢大在讲这些东西时还给我们展示了一下代码，很赞！
上一部分的内容基本是内部传输部分，从中心服务器分发到IDC。接下来是另一部分，调度器的设计部分。
调度器设计就是要考虑，根据网络情况，地理位置，当前各个服务器负载等等，来一个下载请求，决定取哪一台机器给用户提供下载服务。
CDN的基本技术，就是通过用户的IP段，查找他属于哪个网络，电信，网通？然后分配相应网络的服务器给用户提供下载。他们以前的做法是，只要找到同网络的服务器后，随机分配一台给用户提供服务。随机分配存在的问题是，服务器的负载不均衡，可能有的机器忙不过来了，而另一些却闲着。
盛大有个IP库，记录了各个IP段所处的网络，对应的分配服务器。这个在代码中谢大是用treap数据结构体存的，treap是一个kv数据结构，通过二叉树进行查找，通过一个随机权值保证树的平衡。我尚不明白这里为什么选用treap数据结构。使用treap数据结构的结点权值，和服务器负载之间是否有关系？不是吧（期间我去WC了，这里漏了一些内容）。
现在添加了负载分配的部分，会给服务器加上状态。比如优先挑选同网络服务器上负荷较低的机器，如果各个机器负荷都是中等的，则随机挑选一个。如果都到满负荷了，这时则不局限于同网络了，从全局服务器中随机挑一个，总不至于给用户返回404吧。
据谢大称，用Go语言实现以后，目前的系统相比以前的传输速度大大提升，传大文件速度是几乎原来的十倍了，小文件的提升也有30%。用户下载也明显变快了。最后谈到了下阶段可做的优化。其中有一点就是处理上行和下载之间的带宽。有时候几十G的文件任务啪一下就过来了，目前是没有限制的，这样会占用大量带宽，对已在进行中的用户服务造成影响。
接着是邵天宇带来的分享。其实我个人觉得他分享的内容跟Go语言的主题并不算太搭，个人觉得他项目中做的很多事情选择别的语言，别的开源库可能会做得更好，并没有突出Go语言的优势，选择Go只是他强烈的个人偏好而已，这个我持保留态度。这是这位同学第一次做这种分享，不管怎么样，即然使用了Go也算是Go语言的实践了，并且内容方面我认为还是比较精彩的。
微博数据分析中，我觉得可以分以下部分看吧，先是数据源的获取，接着是数据存储，然后是数据分析。
他先给我们介绍了他的开源库的选型。数据源的获取中，他是自己写的爬虫抓取微博的数据，给我们展示了Go的interface在这里的使用，一个url加一个handler。分词和索引方面之前他尝试用wukong的Go语言开源库，但是这个库有个问题是不做持久化，数据全部存放在内存的。内存占用量非常大，在与作者沟通并没得到满意的解决之后，转而使用Es..search(名字记不清了)【是：Elasticsearch + IK 】。列举了好多的开源项目，相信他是做了不少的调研工作。
还提到了他们以前系统是用php做的，硬件用的16核CPU，32G内存，而现在改用Go语言之后只用普通的PC机就能跑了。他还列举了好多数据，微博的活跃用户数啦，抓取的记录数啦，各种...反正是用数据说话，不明觉历啊，呵呵。【在这里我要提一下，他说原来是用python的】
由韩拓给我们分享的，标题临时换了一下，他坦承"golang与高强度在线服务"这个标题有点太装B了。这个分享就比较高度抽象了，没有谈具体的项目，算是一些Go的使用经验吧。
中间有很多，我能记得的包括他们公司的panic是不能抛到进程级别的，必须在goroutine捕获。
像内存使用方面，不使用Go做大内存(大于1G)的服务。合适的东西做合适的事，这是我的感触，比如Go+memcached。主要是Go的垃圾回收不算完善，大量内存分配，回收时会卡。而C语言写的像memcached什么，肯定更专业。
http作为最基本的通信协议。
cgo是尽量避免不要使用的，即使像音频视频转码这类的，只有C的库，他们的做法是用C程序写成服务了让Go去调。
还有什么内存对齐，大多都是七牛公司踩过坑之后约定的一些使用习惯。给我印象比较深的是他们的log处理，他们重写了log的包，提供程序log和事务log两类日志。
---
更详细的请看上述链接。比我写的好多了啦 。
Submitted by gouki on 2013, September 14, 10:51 PM
今天鼠标的左键突然失效，这是用mac系统以来第一次发生这种事情。让我非常震精，因为刚刚升级到了10.8.5，我以为是升级导致的，所以我google了一下，居然发现很多人有这样的问题。
看这里：http://bbs.weiphone.com/read-htm-tid-5168399.html
有人的解决方法是：关上盖子，等一段时间就好了
有人的解决方法是：关闭蓝牙，再重启
当然也有人选择了重启蓝牙鼠标，这TMD居然也正常了？（因为原来连触摸版的左键也不正常，所以才纳闷）
所以我比上文中那位关闭蓝牙鼠标的人幸运多了。不知道以后还会不会发生类似情况。做个记录。。
Submitted by gouki on 2013, September 14, 9:57 PM
我不知道别人是否和我一样喜欢记录点东西，但是我知道我必须要记，因为年纪大了，如果不记录下来，很可能什么都忘了。
(伤心，我大约写了将近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消耗大量的时间，每个人都有一些自己的看法，其实这个话题之前在知乎上已经有人讨论过：
300多毫秒，韩拓说他们遇到过是5秒左右，在线上运行的时候，gc停止了5秒左右。5秒对于我们来说没有什么，但对于一个做高可用的企业来说，已经是有点夸张了。
----
实在不想写了，很痛苦。之前写的全没了，就记录这么一点吧。(这次写的时候，居然又超时了，所幸我ctrl+s，保存了下来。天啊。。。我快崩溃了)
| « 2025年07月 » | ||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
[649] [9] [38] [14] [2] [12] [307] [65] [284] [227] [161] [235] [9] [25] [12] [966] [92]