星期五,2009-08-14 at 9:56 下午
这个标题有点吓人，又是负载均衡又是缓存，随便哪个都能写好几本书了，这里浅谈一二，适合新手，老鸟请绕道，个人的一些浅薄观点。
很多大公司在七层上做负载均衡大多基于硬件，比如F5，假如流量真的大到不行了，或者是钱多的烧包，那么买一个这种设备肯定是不二的选择，省去多少事情啊，不用搭建环境，不用搞很多测试，只要照着说明文档或者去厂方培训几天就可以了。
七层设备出了F5还有很多，在七层上做负载均衡的软件业很多，比如大名鼎鼎的HaProxy，比如配上第三方工具的LVS，甚至因为负载均衡的重要性，很多具有前瞻性的Web服务器开始提供这样的功能，比如nginx，比如light httpd，nginx的七层负载均衡实际上还是很不完善的，当后端代理一台机器死掉后，nginx还会发送请求给这个机器，这个机器不处理，那么nginx就会一直等待超时，在超时后再将请求分配给其他的机器，在流量大时会很影响性能，造成一定程度的连接堆积甚至堵塞，nginx的负载均衡算法也相对少很多，没有haproxy和LVS多，当然后者是专业负载均衡软件。
静态文件缓存也有很多，比如不朽的squid，比如最近两年很火的varnish，甚至号称比squid更快速更精准的nginx的模块ncache,varnish使用的Visual Page Cache技术能够显著降低内存和磁盘的交换次数，使系统利用率更高，我没有在百万级以上环境检测过varnish，很多人说varnish不是足够的稳定，我测试的时候没有发生什么问题。
静态文件缓存一般都不止一台，我一直推崇使用七层负载均衡来设计静态缓存架构，因为可以降低重复率，降低重复率自然是提高利用率。URL HASH能够很好的解决缓存浪费的情况，比如用户头像放在一台机器上，模板中的小文件放在另外一台机器上，利用七层负载均衡就很容易让头像的请求命中头像服务器，模板请求命中模板缓存服务器，避免了三层或者四层负载均衡重复缓存导致的硬件利用率低下问题。而且服务单一，新切换的缓存机器，很容易重新缓存满。
七层负载均衡和四层负载均衡相比，最大的缺点就是没有四层的负载能力高，Haproxy据说能跑到40万并发，LVS有几百万，这些都是理论上的数据，真的跑到40万的时候，服务器网卡早就挂了
星期五,2009-08-07 at 11:02 上午
新入公司，项目被老同志分的七七八八，系统还没有足够的熟悉，暂时清闲了几天，看了几天的代码，有面向对象的，更多的是面向过程的，这篇博文的title值得商榷的，反正我不知道该取什么名字，姑且唬人一下。
1）设计目标，任何软件都需要一个设计目标，比如目标用户，并发数等等，论坛这个东西实时性很强，同时在线人数一般不高，如果很高的话一般会自己做，或者请公司定制开发或优化。撑死了几千人同时在线，很多论坛的设计目标就是没有目标，看到好的功能和界面，拿过来，改改，堆上去，完事
2）模块划分，市面上的几个论坛软件大多还是沿用了N多年前的架构，面向过程，而且过程不清晰，虽然在用户后台看上去好像各个功能挺独立的，看看代码就知道，里面定义了一堆全局变量，更奇怪的是没有注释，还有好几个是没用的，代码重复率非常高，require来include去，绕啊，绕啊，我就晕了~~，功能模块都没能独立，更没法谈耦合和内聚了~
3）数据库设计，这个挺有意思的，曾经“有幸”阅读过discuz不知道几点几版本的代码，里面的SQL写得令人毛骨悚然，不得不佩服写这个SQL语句程序员的数据库造诣之深，反正我是没写过，也写不出来，我的原则是，能一次查询的不做两次查，能不用jion的就坚决不用，discuz的表有上百个之多，phpwind更是超过150个，且有不断增加之趋势，清一色使用mysql，而且还是用的MYISAM引擎，好吧，1000个并发的时候，discuz 7是挂掉了，phpwind没测试过，暂时不评论。数据表设计时冗余是必要的，不一定非要遵循范式规则，过度随意就成了灾难，我看到数据库中居然有q1,q2,q3一直到q21这样的字段，通通都是int型的，而且绝大部分都是空的，浪费空间之严重令人非常惊讶，且不说这个命名十分之不友好，这个东西能这样做的么，假如真的需要21个同样类型的q这种东西，为啥不再分一张表，然后给个ID连接一下不就好了么，这仅仅是一个例子，N张表都能找到这样的例子。用户表是论坛的核心表之一，论坛有积分啊，签名啊，生日啊，等级啊，权限啊之类之类的，用户属性自然是多之又多，可是再多也不能全放一个表里，一个表里有六七十个属性，这像话么！！绝大部分属性普通用户都是空的，又是一个“占着茅坑不拉屎”的表设计，大部分用户注册时能不填的肯定不会填，就那么昵称啊，email啊，密码啊几个字段需要insert，至于牵动六七十个属性同时更改一遍么，myisam引擎insert是加的是表级锁的啊，郁闷，纵向拆分这张表！
4）错误处理，出错了，前面加个@好了，让别人都看不到就不会有什么问题了，嗯，这个似乎是可以防止因为出错信息而泄漏一些东西，可是总得让自己知道怎么回事啊，不然怎么解决呢，还好都有官方论坛可以去问，大多数时候管理员也不知道用户出了什么问题，只能靠猜，为什么不记录一个log呢？！
5）不想说了~~先把前面的改了再说……
星期天,2009-08-02 at 11:39 上午
进程是操作系统最基本抽象之一。一个进程就是处于执行器的程序（目标码粗放在某种介质上）。但进程不仅仅局限于一段可执行程序代码（Unix称之为text section），通常进程还包括其他资源，如打开的文件、挂起的信号、内核内部的数据、处理器状态、地址空间及一个和多个执行线程、当然还包括用来存放全局变量的数据段等，实际上，进程就是正在执行的程序代码的活标本。
1）进程描述符及任务结构
在很多介绍Linux进程描述的文章中，有些将内核的进程存放称之为task array，在阅读linux/sched.h头文件中代码可知，实际上进程存放是以链表的形式存放的，单个数据结构是一个task_struct的结构，因此叫做task list更准确一些。task_struct相对比较大，在32位机器上，大约1.7k。Linux通过slab分配器来分配task_struct，用这个来分配的好处是能达到对象复用和cache coloring（翻译成“缓存着色”太别扭了，也很难理解），实际上就是一个预分配的过程，这样可以减少动态创建和销毁带来的系列开销。
2）进程描述存放
内核通过唯一的进程标示值来存放和标示每个进程（PID）。PID默认的最大值为32768，是int类型，可以增加到类型允许的最大值，对于普通的桌面系统或者server来说默认最大值已经足够，对于大型服务器可能需要更多的进程数，只需要修改/proc/sys/kernel/pid_max来提高上限。
3）进程状态
TASK_RUNNING，进程正在执行，用户空间的唯一状态
TASK_INTERRUPTIBLE，被阻塞，等待恢复的状态。
TASK_UNINTERUPTIBLE ，除了不因为接收到信号而唤醒之外，和上面的一个相同
TASK_ZOMBIE 僵死。
TASK_STOPPED进程停止运行，没有运行，也不能投入运行。
星期五,2009-07-31 at 1:12 上午
人这种动物真的很奇怪，大多时候都总是做着利己的事情，很多时候却选择了不能因为自己而活着的方式。
Livid曾经形容上海是个妖怪的城市，结果他终于躲到了杭州去了，我没去过昆明，不知道昆明是不是Livid说的那样美好，我时常去杭州逛逛，深知杭州没有那么好，至少交通不是很好，堵车是我最不喜欢的事情，偏偏杭州这个事情最常见。
2008年8月我进入Blogbus工作，明天我将从这个我从前到现在一直喜欢的公司里面走出，我不知道从这里带走的小资情调能不能融入新的公司，没有办公室政治的Blogbus是我过得最快乐的一年。
杭州并没有传说中的那么人杰地灵，我将要去这个地方，我深知这个地方的牛人都是外来的，杭州没有上海那么排外，上海制定了很多排外的政策，比如外地车就不能在一定时段上高架，比如上海户口的就一定得交公积金和三险，外地人则可有可无，走在是上海的小巷中，总能听到“乡下人”来形容外地人，好吧，外地就外地吧，中国的户籍制度把人强分成农业户口和城市户口，再把城市户口分成外地户口和本地户口，再把本地户口分成市区户口和郊区户口……
对于一个应届生来说，在同学都急着找不到工作的时候，却频频接到传说中猎头的电话，我是幸运的，凭心而论，我不是很优秀，我的很多专业的知识来自于Blogbus师长的传授，有神仙，车东，刚哥，曹宇伟，唐珂，张捷和潘建龙，在UI和HTML等前端技术方面给我帮助的有，李飞，吴旋，姐夫，还有已经离职的小光大哥和陈小新,在产品方面给我指导的也有很多，蔡溪哲，张新玲和夏添，以上排名不分先后，我是想到哪个写到哪个，在经济上帮助过我的还有姐姐，Blogbus除了一条小狗，一个小猫，两只乌龟还两只被猫吃掉的小鱼非常可爱之外，还有平儿，小U，小花，还有杂志的徐帆姐姐等等
离开是为了更好的发展和长大，也许过于一帆风顺对我没有好处，我想去吃点苦头，顺便交几个难友，多认识几个同事~~外面的世界很大，又一次选择了不光为自己而活着……
星期四,2009-07-23 at 12:30 上午
1) 不要相信任何第三方，即使是你的兄弟开的公司，也不一定跟你说真话，因为很多话是不能跟你说的，第三方和你合作的唯一目的就是钱，当然公司间的合作本来就是利益合作，这本无可厚非，但是总有人利用信息不对称，对灌输给你的信息做对他更有益的改动，然后在合作后频频跳票，不兑现承诺，所以对付第三方的唯一办法就是，找一堆供应商，然后让他们把承诺统统变成白纸黑子，然后挨家比较，选中了之后，把这些白纸黑子变成合同条款，不然拒签。还好上海是一个还算守法律的城市，基本上写进合同的都能兑现，不能兑现都会给一个合理的赔偿或者置换。
2）网站运行速度慢，第一个要检查的是数据库，而不是程序逻辑
3）如果有服务出现了故障，大多是程序本身出了问题，前提是服务器和网络没有异常的情况下，所以无论你愿不愿意都最好能重现一下错误，这是解决问题的最好办法
4）服务器服务调整是个慢工细活，动之前大脑里应该清楚每个细节，如果不熟悉，最好用纸写下来，然后再仔细想想，然后再开始做，假如你和曹宇伟 一样牛逼或者比他更牛逼，能够把shell运用的出神入化，那另当别论
5）文档是最好的老师，网上的那些免费的收费的电子书，都是文档加上作者的理解写成的，假如英文尚可的话，还是直接阅读文档的比较好，我如果遇到一个新的东西，我一般会查一下中文的介绍，大致了解一番，然后去阅读手册，有时候想啊，手册这么好的东西，怎么就没人翻译一下呢，每每冲动去翻译几个手册，苦于乱七八糟的事情和心情太多，浪费了很多时间。
6）不要太相信国内所谓的牛逼的公司的牛逼的人的推介的书，基本上都是炒作，书本身并没有太大的价值，比如《Apache源码分析》和 《走出软件作坊》，作序者都很狡猾，基本上不会提及书的任何内容，当然也可能是作序者根本没看过自己作序的这本书，所以里面大多介绍作者是怎么样一个人，作者的团队、背景甚至认识过程等等，这点在阿里DBA简朝阳先生《mysql 性能调优与架构设计》中尤为突出，那么多所谓的牛人作序，没有一个提及书的内容，不过简朝阳先生的性能调优几个章节还是值得一读的，架构设计不过是一带而过，我觉得不应该放在书名中，名不副实。
7）***权威指南 都是骗初学者的，大段大段的抄手册里面的内容，初学者因为不熟悉所学技术的手册，可能会觉得这种书很详实，用到的都有，其实如果去翻下手册，就知道，还有比这个写的更好的，所以手册不仅是最好的老师，也是最权威的权威指南。
8）不要因为技术而技术，这点对技术人员非常重要，大多数技术人员都喜欢更新的东西，确实，新的东西比旧的东西在多数时候更强大，但你的需求真的需要那些新的功能么？如果花了很大的力气研究一门新的东西，然后只用到老的东西里面也有东西，那么就是浪费了，所以，能满足需求的就是最好的。
9）scalable 在国内都翻译成“可扩展”，比如《构建可扩展的Web站点》一书就是这么翻译的，事实上，应该翻译成“可伸缩”，大部分时候你的网站随着流量的不断增长，服务和设备保持着一种扩张的状态，当我们上了一个可以扩展的解决方案之后，它能不能收缩呢？万一某个时刻我们发现这些东西不是想象中那么好用或者有用，毕竟有些东西需要很大成本的，比如51.com前些日子就裁掉了整个宁波机房，我们是否可以退回去？
10）过程是需要的，谁也不能一蹴而就，一步登天，成功的人都是认真的活到他成功的那一天，急躁只会令自己丧失和浪费更多的时间