开源的互联网

监控宝除了默认的短信、邮件、Gtalk、MSN告警通之外，现在又增加URL回调告警方式。不管你是运维人员还是开发人员，你会发现URL回调可以让你更自由、更灵活的处理告警事件。

首先你需要在全局的通知方式中设置URL回调的有关信息，

填写能通过公网访问到的回调URL，监控宝将会以GET方式传递参数，回调Token是来做数据校验，你需要根据Token来检查请求的合法性。你可以点击“获取模拟回调请求地址”来获得你的测试地址，以便你调试和开发， 最后开启回调。

然后就是在某个具体监控项目的告警方式中开启URL回调功能了，

这样如果有告警消息发生，监控宝会将消息发送到你指定的URL上。

详细的URL回调开发文档可以参考 URL回调开发文档 。

你能充分的发挥想象将URL回调应用到不同的应用中去，比如故障转移。举个例子，有很多人都在使用 DNSPod 的域名解析服务，如果你有多个服务器，发现某个服务器出现问题时，你可能需要登录到DNSPod的系统上，然后从DNS解析中摘除这台机器，想象如果是深夜出现这样的情况，恐怕这晚你的睡眠就被。。。 ，往往这样不确定的情况都会让运维或者开发人员感到心烦。

那么如果使用URL回调功能结合DNSPod开放的API服务，就能做到自动故障转移，监控宝能在第一时间监测到你的哪个服务器出现问题，然后将告警消息URL回调到你的程序，你的程序完全可以通过DNSPod的API去摘除问题服务器。DNSPod API 文档 。你可以不必半夜起来打开电脑，然后修改DNS记录。

通过URL回调你就能更及时更方便的做到故障转移。

TTserver运维方案
note：示例数据库目录 /data/ttserver_data

* 配置TTserver服务器的启动脚本

安装ttserver后默认在/usr/local/sbin目录下有ttservctl启动脚本示例，建议copy到具体ttserver数据存放
的目录（一个机器可能有多个ttserver服务器，分开便于配置和管理）
cp /usr/local/sbin/ttservctl /data/ttserver_data/;
cd /data/ttserver_data;
配置启动脚本ttservctl , vim ttservctl；如：

# configuration variables
basedir="/data/ttserver_data" #数据库目录
port="1978" #ttserver端口
ulimsiz="256m" #对单个ulog文件限制，超过将新建一个文件
sid=1 #server id同mysql，不能有重复的
mhost="remotehost1" #master的地址
mport="1978" #master端口
extfile="$basedir/ext.lua" #lua扩展脚本文件，默认ttservctl没有这项，如果要使用lua扩展请加上，
#并在启动脚本下面的逻辑代码中增加相应判断。
rtsfile="$basedir/rts" #replication的时间记录文件
dbname="$basedir/database_name.tch#bnum=bucket数量#xmsiz=最大使用内存"
#数据库名称及优化参数（“#”后面参数，根据需求配置，bnum推荐为记录数0.5-4倍，xmsiz理论上越大性能越好，
默认64M，也可以使用默认配置，去掉“#”后面参数即可启动）

启动ttserver服务器：./ttservctl start ； 关闭ttserver服务器：./ttservctl stop ;

note:可以放入rc.local中, ttserver启动脚本如果错误会有提示，也可以检查端口是否启用来确定ttserver的启动是否成功

* TTserver的监控

监控命令：tcrmgr inform -st -port 服务器使用的端口 监控服务地址
监控程序提供数据项包括：内存使用，数据文件大小,读写次数，未命中key数量等，由cacti定时读取实现监控
示例地址：http://.../cacti/graph.php?action=view&rra_id=all&local_graph_id=1050
增加磁盘io监控，iotop （iotop要求linux内核2.6.20以上）

note：具体阀值可以设定iotop占总量的80%

* TTserver的备份

全量热备份

备份命令为：tcrmgr copy -port 1978 localhost dpath.tch.xxxxx (其中xxxxx为备份时间)
根据业务需求及数据库运行状态决定备份的频度,全量热备时数据库库会写锁定，读不受影响。全量备份需记录备份时间点以
提供replication恢复时所用，时间记录点精确的微妙，可记录到备份文件名中，如backup.tch.1259474040630024。

示例备份脚本：
[ -n "$1" ] || { echo "input port number"; exit; }
[ -n "$2" ] || { echo "input backup dir"; exit; }

backup_date=`date +%s%N`
backup_date=`expr $backup_date / 1000`
tcrmgr copy -port ${1} localhost ${2}/backup_${1}.tch.${backup_date}
echo "back up finish! ${2}/backup_${1}.tch.${backup_date}"

增量备份ulog
ttserver产生的ulog在"$basedir/ulog"目录，设置了ulimsiz后会按文件尺寸进行切割并按数据升序命名，可以根据备份的
频度，按ulog文件最后修改时间，备份到ulog最大命名数字的前一个文件，同时也需记录备份时间，可将时间记录在打包备
份的文件名中，如backup_ulog.1259474040630024.tar.gz, 和全量备份一样，精确到微妙。

note：全量备份速度和服务器情况有关，基本接近直接copy速度

* TTserver的恢复

使用replication恢复
根据备份方案中数据库全量备份方法得到的备份库，如backup.tch.xxxxxx ,
echo xxxxxx > "$basedir/rts" 写入备份时间点，即恢复时间点
cp backup.tch.xxxxx database_name.tch
启动: ./ttservctl start
恢复的库会根据时间点去master库同步数据，实现恢复

使用日志增量恢复

先使用前一个全量备份的数据库文件作为基数据库，下线要整理的ttserver。

清空原来的日志，然后解压，再cp 备份的ulog文件 $basedir/ulog/ ，
echo xxxxxx > "$basedir/rts" 写入备份时间点（压缩文件名中包含），即恢复时间点
单独启动ttserver ： ttserver database_name.tch
从日志恢复：tcrmgr restore -port port -rcc localhost ulog
ctrl+c停掉ttserver，然后使用 ./ttservctl start 启动，master结构重新建立

note:日志增量恢复环节应避免受其他ttserver的服务器影响，如可以使用一个不使用的端口进行恢复，这样数据也不会影

响到其他服务器，恢复后再用原来的启动脚本启动，形成原来的dual master结构

* TTserver优化

定期优化，整理数据文件碎片，优化命令：
tcrmgr optimize -port port host

note：整理时会锁库，读写都锁定

* 备注

基于dual master的结构具有较高的可靠性，dual master其实就是实时的热备方案，所以在备份频度和广度上是否可以

适当宽松一些？建议每天备份全量即可，增量的日志一直留在服务器上，但是日志的分割尺寸要根据业务和恢复的粒度来确定。

Fusion- io表示他们最新的固态硬盘（SSD）的参数为持续读取带宽 1.5GB/s、读取IOPS（I/Os Per Second） 186,000、持续写入带宽 1.4GB/s、写入IOPS 167,000，是由他们320G的SSD产品达到的。相比较而言，低端SATA硬盘驱动器（HDD）的随机IOPS可以达到70，而高端SAS硬盘型号的随机IOPS可以达到300。该SSD产品是一款PCI-Express外设卡（PCIe），平均访问延迟低于50微秒，而相比之下，硬盘的平均访问延迟是4.5毫秒，即4500微秒。
最新SSD比HDD.SAS等的硬盘型号的性能已经高出了几个数量级，SDD的主要优势在：
* 用电量更低——服务器上一块SSD的功耗大概是3瓦，而类似的一块HDD则在6至10瓦之间。
* 更快的查寻速度——如上所述，SSD的查寻时间在随机读取方面至少比HDD要快得多：SSD的查寻时间约为100微秒，而HDD平均是4500微秒。
* 更高的可靠性——缺少活动部件，意味着SSD出现硬盘硬件故障的可能性比HDD要小得多。根据公布的数据，SSD的平均无故障时间（MTBF）约为200万小时，而HDD则仅为其六分之一，约为30万小时。
* 工作静音——SSD运行时完全静音，硬盘驱动器则绝对不可能。
阻碍SSD应用的最大障碍是价格——64 GB SSD的价格仍然约为同等存储容量HHD的4倍。然而，任职于Ars Technica的Jon Stokes指出，由于数据中心的散热和耗电引起更多的关注，SSD相较于HDD更低的运营成本导致两种解决方案的总体价格也非常接近。
当然，SSD适合对磁盘操作密集，高并发的应用服务器，综合成本也许更低，我们也有理由相信SSD硬盘的价格会不断的下降到普及。

每次启动gearmand都要敲很多参数，干脆写到一起，直接start和stop就可以了，

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

#! /bin/sh
 
#----------------------------------------------------------------
# Startup script for the server of Gearmand
#----------------------------------------------------------------
 
# configuration variables
prog="Gearmand"
cmd="/home/tanbin/g/gearmand"
basedir="/home/tanbin/g/a"
port="4730"
pidfile="$basedir/pid"
logfile="$basedir/log"
 
retval=0
 
# setting environment variables
LANG=C
LC_ALL=C
PATH="$PATH:/sbin:/usr/sbin:/usr/local/sbin"
export LANG LC_ALL PATH
 
# start the server
start(){
  printf 'Starting the server of Gearmandn'
  mkdir -p "$basedir"
  if [ -z "$basedir" ]  [ -z "$port" ]  [ -z "$pidfile" ]  then
    printf 'Invalid configurationn'
    retval=1
  elif ! [ -d "$basedir" ]  then
    printf 'No such directory: %sn' "$basedir"
    retval=1
  elif [ -f "$pidfile" ]  then
    pid=`cat "$pidfile"`
    printf 'Existing process: %dn' "$pid"
    retval=1
  else
    cmd="$cmd -d -p $port -P $pidfile"
    if [ -n "$logfile" ]  then
      cmd="$cmd -l $logfile"
    fi
    printf "Executing: %sn" "$cmd"
    cmd="$cmd $dbname"
    $cmd
    if [ "$?" -eq 0 ]  then
      printf 'Donen'
    else
      printf 'The server could not startedn'
      retval=1
    fi
  fi
}
 
 
# stop the server
stop(){
  printf 'Stopping the server of Tokyo Tyrantn'
  if [ -f "$pidfile" ]  then
    pid=`cat "$pidfile"`
    printf "Sending the terminal signal to the process: %sn" "$pid"
    kill -TERM "$pid"
    c=0
    while true  do
      sleep 0.1
      if [ -f "$pidfile" ]  then
        c=`expr $c + 1`
        if [ "$c" -ge 100 ]  then
          printf 'Hanging process: %dn' "$pid"
          retval=1
          break
        fi
      else
        printf 'Donen'
        break
      fi
    done
  else
    printf 'No process foundn'
    retval=1
  fi
}
 
# send HUP to the server for log rotation
hup(){
  printf 'Sending HUP signal to the server of Tokyo Tyrantn'
  if [ -f "$pidfile" ]  then
    pid=`cat "$pidfile"`
    printf "Sending the hangup signal to the process: %sn" "$pid"
    kill -HUP "$pid"
    printf 'Donen'
  else
    printf 'No process foundn'
    retval=1
  fi
}
 
# check permission
if [ -d "$basedir" ] && ! touch "$basedir/$$" >/dev/null 2>&1
then
  printf 'Permission deniedn'
  exit 1
fi
rm -f "$basedir/$$"
 
 
# dispatch the command
case "$1" in
start)
  start
  
stop)
  stop
  
restart)
  stop
  start
  
hup)
  hup
  
*)
  printf 'Usage: %s {startstoprestarthup}n' "$prog"
  exit 1
  
esac
 
# exit
exit "$retval"
 
# END OF FILE

脚本非常简单，其实看过ttservctl的启动脚本的人会发现这就是copy过来了，呵呵。

安装php tokyo_tyrant扩展的系统要求为：

1

This extension requires Tokyo Cabinet, Tokyo Tyrant and PHP version 5.2.0+.

如果你只是作为client来使用ttserver，而不想安装tokyo cabinet和tokyo tyrant，因为仅仅是作为client而已，
没必要增加安装的复杂度，所以制作了免安装版的php tokyo_tyrant扩展（其实只是so文件打包而已，没有技术含量）
安装要求至少服务器操作系统一致，php是编译安装的，我使用的是centos系统，好了，发上包：

下载

注:如果安装出了问题可以用ldd tokyo_tyrant.so查看一下各个库的链接情况即可自己解决了，呵呵

最近要用到分布式持久化存储的东西，研究了一下memcachedb和tokyo cabinet & tokyo tyrant，把做到ppt共享出来，
欢迎拍砖。。。。

分布式持久化key-value存储.pdf

以前就听说过memcachedb了，但是一直也没有直接的使用上，最近项目中要用到，所以写点使用的总结，

1.介绍：

说这个肯定是废话，还是一句话说一下，使用memcache协议，分布能力来使用Berkeley db，也不知道这样准不准确。

1.安装：

官方中说的很清楚，摘录一下就可以，另外，如果ubuntu安装libenvent可以使用

apt-get install libevent1

其他的就需要编译安装了：

Berkeley DB 4.7 or later
-------------------------
http://www.oracle.com/database/berkeley-db/db/index.html

How to install BerkekeyDB:

$tar xvzf db-4.7.25.tar.gz
$cd db-4.7.25/
$cd build_unix/
$../dist/configure
$make
$sudo make install

libevent 1.3e or later
-------------------------
http://monkey.org/~provos/libevent/

How to install libevent:

$tar xvzf libevent-1.3e.tar.gz
$cd libevent-1.3e
$./configure
$make
$sudo make install

Load .so file by add two line in /etc/ld.so.conf:

  /usr/local/lib
  /usr/local/BerkeleyDB.4.7/lib

Then, run 'ldconfig'.

Installation
============
$tar xvzf memcachedb-X.Y.Z.tar.gz
$cd memcachedb-X.Y.Z
$./configure --enable-threads
$make
$sudo make install

这段是官方的，不需多解释了，安装好后启动了：

memcachedb -p21201 -d -r -u root -H ./env -N -v

解释一下，“./env”是data的目录，这个可以自己设定，这个数据是可以移植的，里面的log文件memcachedb会清理，数据文件会不会动的（废话）。
安装好后使用php的memcache扩展就可以了：

$mdb = new Memcache();
$mdb->connect('localhost', 21201);
$mdb->set($key, $result);
$value = $mdb->get($key);

这些基本的操作和对memcached的是一样，基本是memcached的协议，看到老版本对key有限制，我使用的1.2是没有这个限制了，和memcache一样，250字符够用了。和memcached不一样的地方，memcachedb（memcached默认限制1M）并没有对value的大小做限制（当然很大的话没有测试），这个是因为存储是Berkeley db，另外有点奇怪的地方，我看到源码包里面的protocal里面有这么一段：

Expiration times
----------------

Some commands involve a client sending some kind of expiration time
(relative to an item or to an operation requested by the client) to
the server. In all such cases, the actual value sent may either be
Unix time (number of seconds since January 1, 1970, as a 32-bit
value), or a number of seconds starting from current time. In the
latter case, this number of seconds may not exceed 60*60*24*30 (number
of seconds in 30 days); if the number sent by a client is larger than
that, the server will consider it to be real Unix time value rather
than an offset from current time.

应该是没有expiration这个概念的啊，自己试了一下，发现的确没有expiration，再到官方discuss里面找，
作者回答其他人提问时也回答没有expire这个概念了。但是为什么官方文档中有这么一段呢？（可能是指memcache协议，但是放到这里会容易让人误解）。

很早以前就听说memcache了，以前也是用memcache，可是却没有对里面的原理有深入一点的研究。

其实网上有一篇很好的文章，是一个哥们翻译过来一篇日本人对memcache原理的介绍，这篇文章实在写的

很好，图文并茂，所以实在没有必要我来这里班门弄斧了，只是在后头补充一些我的想法而已。

先上地址： http://tech.idv2.com/2008/08/17/memcached-pdf/

补充一些，首先，有个很好用的图形工具可以帮助我们监控和分析memcache，以前我的文章中提到过：

http://www.codytan.com/?p=479

我认为对memcache进行Flush操作后，会让所有的数据过期，除标志为过期外，但是key依然存在，这个用上面的图形工具查看slab和item就能看到，对于过期的数据，memcache

并不会去理会，也会保存value所在，只有当get来触发的时候，会delete这个对应的key.

这里在说一些内存分配的东西，这些其实才是重点：

memcached在启动的时候可以用-f 指定chunk的增量倍数，我们这里叫他因子吧，默认的是1.25，

你会发现启动memcache会分配40个slab class，这个并不是固定的，而是因为chunk × 个数 就要超过

1M了，memcached对一个slab固定为1M，所以里面的元素chunk自然也是小于1M的，同样，超过1M的数据是无法

保存到memcache里面的（使用压缩参数除外），当slab里面的空闲chunk用完了，memcached会有两种方式来处理新来的item，这个取决于是否已经到了memcached的limit memory了，如果还有空闲的内存，会分配新的slab，再被成chunk，
如果已经满了，则会对相同size的数据优先进行LRU（针对slab class）。
所以如果一开始服务器都保存小的数据，会把空余的内存先分配掉了，到后来留给大的文件就更少，当然大的文件进行的LRU就更多了。

还有很多同学可能喜欢用memcache来做统计，注意不要类似的代码：

$count = $memcache->get(key);
$count++;
$memcache->set(key);

这样会因为并非的问题而造成统计的不准确，可以使用memcache->increment，
到达数量后保存到数据库，代码略了。

如果有什么错误请email我。

大家都使用memcache，当然需要经常看看运行的状况了，

可以使用telnet 。。。。。（在以前的文章中有介绍过了）

其实有更方便的，pecl里面就有memcache.php文件，

打开文件修改密码，修改主机（可以监控多台服务器），如：

define('ADMIN_USERNAME','memcache'); 	// Admin Username
define('ADMIN_PASSWORD','password');  	// Admin Password
define('DATE_FORMAT','Y/m/d H:i:s');
define('GRAPH_SIZE',200);
define('MAX_ITEM_DUMP',50);
$MEMCACHE_SERVERS[] = 'localhost:11211';

然后登录，可以看到如图的统计结果：

一篇老外写的文章，总结的不错，拿来分享了

SCALABILITY BEST PRACTICES

Here are a baker’s dozen of items that we feel are Best Practices for Scalability:

1.     Asynchronous - Use asynchronous communication when possible. Synchronous calls tie the availability of the two services together. If one has a failure or is slow the other one is affected.

2.     Swim Lanes – Create fault isolated “swim lanes” of hardware by customer segmentation. This prevents problems with one customer from causing issues across all customers. This also helps with diagnosis of issues and code roll outs.

3.     Cache - Make use of cache at multiple layers including object caches in front of databases (such as memcached), page or item caches for content (such as squid) and edge caches (such as Akamai).

4.     Monitoring - Understand your application’s performance from a customer’s perspective. Monitor outside of your network and have tests that simulate a real user’s experience. Also monitor the internal working of the application in terms of query and transaction execution count and timing.

5.     Replication - Replicate databases for recovery as well as to off load reads to multiple instances.

6.     Sharding - Split the application and databases by service and / or by customer using a modulus. While this requires slightly more complicated logic in the application it allows for massive scaling.

7.     Use Few RDBMS Features – Use the OLTP database as a persistent storage device as much as possible. The more you rely on the features offered in most RDBMS for your transactions, the greater load you are putting on the hardest item in your system to scale. Remove all business logic from the database such as stored procedures and move it into the application. When significant scaling is required join in the application and not through the SQL.

8.     Slow Roll – Roll out new code versions slowly, to a small subset of your servers without bringing the entire site down. This requires that all code be backwards compatible because you will have two versions of code running in production during the roll out. This method allows you to find problems that your quality and L&P testing missed while having minimal impact on customers.

9.     Load & Performance Testing – Test the performance of the application version before it goes into production. This will not catch all the issues, which is why you need the ability to rollback, but it is very worthwhile.

10. Capacity Planning / Scalability Summits – Know how much capacity you have on all tiers and services in your system. UseScalability Summits to plan for the increased capacity demands.

11. Rollback – Always have the ability to rollback a code release.

12. Root Cause Analysis - Ensure you have a learning culture that is evident by utilizing Root Cause Analysis to find and fix the real cause of issues.

13. Quality From The Beginning – Quality can’t be tested into a product, it must be designed in from the beginning.