The Mirages

分而治之就是化整为零。古代有曹冲称象这种绝妙的应用。
而最近看了很多计算机书，发现很多现有的技术其实就是分而治之的范例。从集中存储到分布式存储，从大型机计算到分布式计算，就算是大型机现在其实也都是由大量的CPU组合起来。
但是集中和分开都是相对的。也许现在我们的分布式计算在若干年后就已经算是集中式计算，这个时间在我看来也就是3年时间。
说点具体的计算机例子吧。
以前我们分析日志从来都是通过log-ng把所有日志同步到一台服务器上，然后集中进行同行。或者在每台服务器上各管各的进行统计。而随着日志量越来越大，每天高达200G的日志量，这就不得不每过几分钟进行统计一次，而当日志量越来越多的时候，那我们学会了用Hadoop进行分布式计算分析完成后再进行汇总。
当然其实在hadoop逻辑内部也是有集中和分发2个部分的。
这篇日志写的有点乱，看来对于逻辑和哲学还是有很大的欠缺。古语有云“无极生太极，太极生阴阳，阴阳生四象，四象生八卦，八卦生六十四个啥，六十四个啥生万物“ 最后这个给忘记了。可见对于万物都是遵循了同一个内部原则，这个不会随着外部的变化而变化，乃是万物生长的法则。
合久必分，分久必合。而计算机技术也在这分分合合中进行了自己的发展。
其实这篇文章主要是看了《构建高性能web站点》的一个书评。全书我觉得最好的部分主要是在前面2章，而后面大多是泛泛而谈了，毕竟对于高性能web站点要考虑的东西太多了，而每个部分都要面面俱到就算是2000页估计也难完成。所以从中主要是了解一个思想，就是上面说的分而治之。
比如对于数据库来说，当我们发现单台数据库没法支撑的时候，我们就会把数据库服务器进行升级硬件以达到新的需求。而再不行的情况下，那就分库，把不同数据库分配到不同服务器上。而一旦一个数据库大到无法想象，那就把这个数据库中的表进行分拆存放到不同服务器上，而再不行那就把单个表分成100份1000份10000份存到不同的服务器上。而这其中就是分而治之的思想。
而一旦你有了这样的思想，你才会想到开发更好的程序来支撑这种需求。
而要构建这个web站点离不开所有互联网人员的努力，不光是技术，还有销售运营等等的配合。

##############################
Best regards
Timo Seven
(http://twitter.com/twitter) UNIX System Admin & MySQL DBA

今天在blog的referer地址中突然发现下面这个链接
http://monitor.admin.t.sina.com.cn/monitor/url_list.php?confirm=0&status=0&stime=2010-09-13%2009%3A50%3A00&etime=2010-09-13%2010%3A00%3A00 想直接访问下居然没法访问，也是正常。用Nslookup一看居然还是个内网地址
Non-authoritative answer:
Name: monitor.admin.t.sina.com.cn Address: 10.68.3.176
那看来只能是新浪内部才可以访问了，可为什么这个居然公网DNS也可以解析，看来这个东西是上的比较着急给遗忘了。
从链接中开能看出这个是通过读取数据库来进行存储的
表结构估计就是上面写的那个
comfirm 默认为0,有问题的估计为1
status 默认为0, 如果为1估计是有问题的
stime
etime
这2个是很明显的发布时间的区间范围
这个东西应该比较山寨，毕竟是匆匆上线的产品。应该还有个简单的用户权限分级和验证系统。
###########################################
Best regards
Timo Seven

web压力测试，之前用过autobench和ab，但是都不是进行乱序测试的，之后看公司wiki发现有人用siege进行乱序测试。

这个东西安装和使用很简单，主要步骤如下

1
2
3
4
5
6
7
8
9
10
11
12
13

 wget ftp://ftp.joedog.org/pub/siege/siege-latest.tar.gz cd siege* ./configure make make install siege -c 1000 -r 100 -i -b -f url.txt 
```  
  
这其中url.txt中是所有需要测试的连接。 -c 表示并发1000， -r表示执行100次， -i表示乱序， -b表示循环100次之间不停顿，默认是停顿1秒  
  
但是siege自身感觉也是有瓶颈的，并发数最大也就1000，再提高就会报下面这样的错误  
  
\[error\] socket: unable to connect sock.c:222: Operation already in progress socket: connection timed out  
  
这样最终导致测试结果怎么都没法超过2W每秒的请求，所以就把siege -c 1000 -r 100 -i -b -f url.txt 放到shell中并发执行  
  
```c
 for i in {1..10} do siege -c 1000 -r 100 -i -b -f url.txt &; done 

这本书是日本人安不司写的，他可是算做日本添加剂之神。
但是看了之后感触最深的并不是添加剂相关的内容，而是其它方面的感触却挺深。
食品添加剂，这个东西以前是肯定是没有的，而是工业时代的产物，是为了方便进行量产，同时作为消费者也有责任，总是喜欢挑选便宜而且看着又好看的了。所以很多制造商为了这些目的就拼命朝这方面努力。
而一旦让孩子知道食物得来的那么容易，那就不会珍惜。很多东西都是这样的，你一旦知道太容易的得到它，那就不会太在乎的。
作者说的那个事情很真实，因为我也经历过这样的事情。当你跟一只小鹅一起长大，突然有一天你父母把小鹅给杀了，做了吃了。我想这个时候你肯定会很珍惜。也许你或许都不会吃。而如果你就加点添加剂就能得到肉的味道，那你会怎么看待呢？
而我想作者其实最想表达的就是这个意思。好了，还是说说不能吃哪些添加剂吧。原理很容易：只要你自己厨房里没有的就得注意了。当然在国内的话一般都会特别标注为添加剂。
添加剂最不好的就是安赛蜜和阿斯巴甜，这2个是作为甜味剂使用的，甜味是蔗糖的2000倍，而价格才是蔗糖的3倍。所以这种是完全不应该添加的。而且据说阿斯巴甜和安赛蜜会导致偏头痛，这2个都在欧洲杯禁用了。而美国也禁用了安赛蜜，而国内还没有禁止。山梨酸和山梨酸钾，这几个都是调酸味的，而且是完全化学合成，所以千万别有。还有亚硝酸钠，各种着色剂，各种BHT，BHA，OPP，TBZ。
而作者认为必不可少的添加剂，对人也没有危害的有：苏打，发酵粉，盐卤，氢氧化钙，琼脂和明胶。
而作为我们消费者来说，不光买东西要看生产日期和保质期，还得特别留意配料表。也不要尽找便宜的。有的时候你吃了添加剂的你再吃自然的就感觉自然的东西不怎么好吃，其实我们都被添加剂给害了我们的味觉。

##############################
Best regards
Timo Seven
(http://twitter.com/twitter) UNIX System Admin & MySQL DBA

其实现在我这本书只看了一半，但是有些想法我觉得还是得记录下来。
我一直是做系统运维的，作者应该是开发出身。书的第二章和第三章主要是讲网络 传输和服务器并发处理能力。
虽然这2部分离非常专业还是差的比较远，但是我觉得作者分析的思路还是很不错
的。普通的系统运维人员一般处理问题就是man一下或者google一下，翻翻WIKI，
查查mail list。但是书的作者因为是开发人员，所以他的视角从一开始就是源 码，系统函数来判断。
其实这样做是非常正确的我觉得，毕竟所有服务器软件最终都是调用系统函数，而 Linux的优势不就是开放源码呀。
其实刚开始这种分析方法帮我解决了几个nginx的问题，首先是epoll，这个I/O模
型到底有哪些优势，为什么会产生epoll，它主要解决了哪些问题，而作者关于那 个面馆的比喻也非常不错，很形象。
另外一个问题是sendfile()方法，启用这个和不启用的区别在哪里？ 而作者通过
strace工具分析也很不错。可以抓取到各个系统函数的调用时间和次数。而通过
strace分析后发现使用sendfile()方法后write()方法就没有了，而write()方法就 是把文件从用户空间往内核空间中进行写。
另外一个是到底开多少nginx进程好呢？ 这个在apache中是不需要配置的，它会自
己根据链接情况增加和减少。nginx进程太少可能就会让其它cpu闲置着，而开启太
多还会导致频繁的上下文切换。虽然这些时间对于1秒种来说是非常微小的，但是 累计起来就大了。
看到一半为什么要写读后感主要是觉得以后排除问题，特别是性能方面的问题有了
全新的解决思路，而这个思路就导致了我必须看下linux内核的源码以及系统软件 的源码，当然wiki还是必须要参考的。
##############################
Best regards
Timo Seven
() UNIX System Admin & MySQL DBA

上个月老婆办了一个招商银行信用卡和卡，说是只要一次消费满288就可以送2张电影票。

下面这个网址是招商银行信用卡对于这个活动的具体说明。

http://www.cardcmb.com/play/others_movie_1.shtml?WT.mc_id=N371400101006250

可老实说这种规定基本属于银行为了规避自己责任的规定，而对于具体如何换票没有特别的说明。

从这里我实在不知道指定电影院是哪里？ 指定到密云难道大家也去吗？ 而且什么叫以实际为准？

为了确认这个问题，老婆直接播了招行信用卡的4008205555电话。而且还拨了3次。但是却得到不同的答案。

由于工作需要，需要用到nginx的很多特性，但是每个层次需要做不同的功能。虽然下面这个日志配置文件可以很好的运行。可我就跟郭欣在《构建高性能web站点》中说的，我还没弄清楚这些日志配置之后的原理。

测试环境

1. 10.1.41.81 client
2. 10.10.72.148 proxy
3. 10.10.72.219 cache
4. 10.10.72.221 real server

日志设置的需求

1. 日志设置的结果需要在所有节点上知道它的上一级IP和用户IP，这样可以方便查找问题 2. 日志设置的第二个目的是在proxy和cache都加了response time和request time 3. 在cache层的日志增加了cache的命中结果，有MISS，EXPIRED,HIT等5种不同状态 4. 在源站加入了gzip的压缩比
5. msec是表示用毫秒表示当前写入日志的时间

意外发现

今天就对keepalived进行了自定义脚本的测试。

先是定义一个vrrp_script
脚本名字，指定测试的内容。也可以自定义脚本，设定执行时间。然后在vrrp_instance中调用就可以了。这样一旦出现无法连接VIP就会自动漂移到其它机器上。

今日还顺便测试了下当2个BACKUP的priority相同，master失效的结果，结果发现VIP会同时漂移到这2台机器，而且你用arping的时候会得到2个mca地址，这是非常危险的，所以我们在一个多播组内千万要设置不同的priority.

同时我们在我昨日的blog中老外写的那个监控脚本有关于weight值的设定，这个我自己测试上加了后发现监控就不生效了，我把80口的nginx直接关了也没有实现VIP漂移。关于这个问题以及发信给作者了，现在还在等回复，官方文档找不到，例子中发现weight有-2，-3，-4，2各种不同，实在是不明白。我自己也没看到直接看源码的程度，还是直接问问得了。

 vrrp_script chk_http_port { script "/tcp/127.0.0.1/80" # 连接本机80端口，正常就退出，无法连接就报错 interval 1 # 每秒连接一次 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 smtp_alert authentication { auth_type PASS auth_pass hdtv } virtual_ipaddress { 10.1.41.141 } track_interface { eth0 #加入网卡部分监控，要实现这个功能也可以不加 } track_script { chk_http_port #上面的vrrp_script的名字 } } 

###########################################

keepalived既可以配合lvs使用，也可以单独使用，所以它的配置文件分为如下几个部分：

2. Global Configuration

3. Global definitions

4. Static routes/addresses

5. Vrrpd Configuration

6. VRRP synchronization group(s)

7. VRRP instance(s)

8. Lvs Configuration

9. Virtual server group(s)

10. Virtual server(s)

这次由于主要用到vrrp instance，所以重点对配置文件这个部分进行解读

下面是对这个配置的解释

 state MASTER|BACKUP #如果不指定Master或者BACKUP,那priority最高的就是master interface eth0 #监听的实际网口 virtual_router_id 51 #组播ID，通过224.0.0.18可以监听到现在已经存在的VRRP ID，最好不要跟现有ID冲突 priority 100 #权重为100，权重数字越大就越高 advert_int 1 #发送组播包的间隔时间，默认为1秒 smtp_alert #发送邮件报警 authentication { auth_type PASS auth_pass hdtv } #这个是验证类型为PASS（明文）,密码为hdtv。验证类型也可以选择IPSEC，但是官方是不推荐的 virtual_ipaddress { 10.1.41.141 } #虚拟IP为10.1.41.141 #############下面这些是文档中存在，但是在上面没有用到的############################# dont_track_primary #忽略网卡错误 track_interface { eth0 eth1 } #监控eth0和eth1这2块网卡的状态 mcast_src_ip #使用这个地址作为多播包的源IP，而不是使用interface eth0上的IP lvs_sync_daemon_interface eth1 #绑定eth1作为lvs同步的 garp_master_delay 2 #master和slave漂移时间改为2秒，默认位5秒，怪不得我昨天发现每次都是5秒才转移 virtual_ipaddress { / brd dev scope label 192.168.200.17/24 dev eth1 192.168.200.18/24 dev eth2 label eth2:1 } #vip可以写成整个网段和某块网卡上的所有IP virtual_ipaddress_excluded { / brd dev scope / brd dev scope ... } #排除哪些IP virtual_routes { src 192.168.100.1 to 192.168.109.0/24 via 192.168.200.254 dev eth1 192.168.110.0/24 via 192.168.200.254 dev eth1 192.168.111.0/24 dev eth2 192.168.112.0/24 via 192.168.100.254 } #当状态切换的时候会增加和删除路由，格式如src \[to\] / via|gw dev scope tab nopreempt #这个参数是用来，当master当掉，slave接替原来的master作为master后，这个时候当master重新起来后，有了这个参数后原来的slave就不会自动再自动切换为slave，而是继续作为master preempt_delay 300 #接上面那个参数，这个表示，只有在老的master重新正常300秒后，老的master才会切换为master，这个参数范围是0-1000，默认为0 notify_master | notify_backup | notify_fault | notify | smtp_alert #各种报警方式，可以定义具体的内容来达到不同的报警信息。 

上面这些是官方的配置文件，下面这些是放狗搜索出来的其它配置，主要是为了做服务状态的检测，不然keepalived只能看网口有没有down掉再进行迁移，那样就要另外写其它的监控脚本来达到当服务挂掉后就把网口down掉。
下面这个是从邮件列表中抄袭而来，但是没有测试过，明日会找时间进行测试。下面这个是在1.1.13版本之后就实现了。

使用keepalived，是因为keepalvied的切换时间非常短，我在Linux用ping进行测试基本4秒左右就可以切换了，这样的时间还是可以接受的。

做LVS最讨厌的就是有太多的机器做LVS的时候会浪费一半的机器。这样其实是非常不合算的。

而heardbeat实在是太麻烦了。keepalived问题就是文档实在不怎么全，最新的完整文档还是2002年的。

在测试环境中我使用了3台机器，其中每台机器都是前端，但是又各自备了其它的其它2个前端。健康检查是通过实际IP进行的，而所有的服务端口都是跑在vip的端口上。vip也可以指定多个。

机器分配如下：

a: 10.1.41.90   vip  10.1.41.141