#seq形式 起始从1开始
for i in `seq 100`
do
    if((i%3==0))
    then
        echo $i
        continue
    fi
done

#while循环注意为方括号[],且注意空格
min=1
max=100
while [ $min -le $max ]
do
    echo $min
    min=`expr $min + 1`
done  

#双括号形式，内部结构有点像C的语法，注意赋值：i=$(($i+1))
i=1
while(($i<100))
do
    if(($i%4==0))
    then
        echo $i
    fi
    i=$(($i+1))
done

#从配置文件读取，并可以控制进程数量
MAX_RUN_NUM=8
cat cfg/res_card_partition.cfg |grep -v '^$'|grep -v "#" | grep -v grep |while read partition 
do        
                nohup sh inv_res_card_process.sh $partition >log/resCard$partition.log 2>&1 &               
                while [ 1 -eq 1 ]
                do
                                psNum=`ps -ef | grep "inv_res_card_process" | grep -v "grep" | wc -l`
                                if [ $psNum -ge $MAX_RUN_NUM ]
                                then
                                              sleep 5
                                else
                                              break
                                 fi                                        
                done                
done

 三.循环控制语句 
    break 命令不执行当前循环体内break下面的语句从当前循环退出. 
    continue 命令是程序在本循体内忽略下面的语句,从循环头开始执行

1、单一职责原则（Single Responsibility Principle，简称SRP）
      单一职责原则，就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者一直 这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。而软件设计真正要做的许多内容，就是发现职责，并把这 些职责相互分离。

      一句话点评：高内聚低耦合的绝佳体现，不要乱拉关系，独善其身挺好。

2、 开放--封闭原则（The Open-Closed Principle简称OCP）
       开放--封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。即对于扩展是开放的，对于更改是封闭的。 我们不可能做到未卜先知，在设计的时候尽可能让一个类足够好，设计好了就不要去修改了；不能完全封闭的情况下，当发生变化时，我们就创建抽象来隔离以后发 生的同类变化。

      一句话点评：开放扩展，封闭更改，开合有度是一门艺术。

3、依赖倒转原则（Dependence Inversion Principle ）
      依赖倒转原则，指高层模块不应该依赖低层模块，两个都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。说白了就是要针对接口编程，不要对实现编程。 举个例子：计算机硬件中，如果内存坏了，那么只需要换一个内存条就可以了，而不需要去换一个主板，在这里内存是一个接口类，只要符合他的规格要求就行，无 论是那一根。

     一句话点评：搞建筑时要做设计师，而不是砖瓦工，抽象的蓝图要靠具体的材料一点点实现。

4、里氏代换原则（Liskov Substitution Principle，简称LSP）
     里氏代换原则，子类型必须能够替换掉他们的父类型。在软件里面，把父类都替换成其子类，程序的行为不会发生变化。正是由于子类型的可替换性才使得使用父类型的模块在无需修改的情况下就可以扩展。

     一句话点评：长辈给了你继承的权利就一定要做赡养的义务，把长辈的职责都要承担起来。

5、迪米特法则（Law of Demeter）
      迪米特法则，如 果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法时，可以通过第三者转发这个调用。类之 间的耦合越弱，就越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。 主要是强调了类之间的松耦合。

     一句话点评：不要和陌生人说话，若两国交战要尽量避免正面冲突，多派使者协商调度。

6、合成/聚合复用原则（Composition/Aggregation Principle]，简称CARP）
     合成聚合复用原则，尽量使用合成/聚合，尽量不使用类继承。合成聚合是“has  a”的关系，而继承是“is  a”的关系。由于继承是一中强耦合的结构，父类变，子类必变。所以不是“is  a”关系，我们一般不要用继承。优先使用合成聚合复用原则，有助于保持每个类的封装，降低继承的层次。
     一句话点评：优生优育，不要盲目繁衍。

为了方便，你还可以这样：

bjam --with-date_time --build-type=complete --toolset=msvc-8.0 stage

注意，--build-type=complete表示生成debug release static shared的各种版本

还有一个非常需要注意的地方，我在一次编译的时候遇见过很变态的问题，由于安装了VS2008，所以我想用VC9来编译，结果VC9的设置似乎与环境变量冲突，在打开命令行工具的时候会提示：此时不应有：<此处为系统的所有环境变量>。这个奇怪的问题很可能是由于环境变量里的路径过长或包含不该有的符号而导致的，但奇怪的是，VS2005并没有这个冲突问题。所以，这时候如果要编译boost的话只有两条路走：1、搞定VS2008的冲突，重装环境变量里路径过长的程序。2、用VS2005的命令行工具去编译。顺带一提的是，这时候最好不要用系统中的cmd，而是在开始->程序->VS2005->工具->命令提示里执行bjam的工作。

其他参考：

bjam参数 --build-dir=<builddir> 编译的临时文件会放在builddir里(这样比较好管理，编译完就可以把它删除了) 
--stagedir=<stagedir> 存放编译后库文件的路径，默认是stage 
--build-type=complete 编译所有版本，不然只会编译一小部分版本（确切地说是相当于:variant=release, threading=multi;link=shared|static;runtime-link=shared） 
variant=debug|release 决定编译什么版本(Debug or Release?) 
link=static|shared 决定使用静态库还是动态库。 
threading=single|multi 决定使用单线程还是多线程库。 
runtime-link=static|shared 决定是静态还是动态链接C/C++标准库。 
--with-<library> 只编译指定的库，如输入--with-regex就只编译regex库了。 
--show-libraries 显示需要编译的库名称

以 libboost_regex-vc71-mt-d-1_34.lib 为例：

·         lib 
前缀：除了Microsoft Windows之外，每一个Boost库的名字都以此字符串开始。在Windows上，只有普通的静态库使用lib前缀；导入库和DLL不使用。

·         boost_regex 
库名称：所有boost库名文件以boost_开头。

·         -vc71 
Toolset 标记：标识了构建该库所用的toolset和版本。

·         -mt 
Threading 标记：标识构建该库启用了多线程支持。不支持多线程的库没有-mt。

·         -d 
ABI标记：编码了影响库和其他编译代码交互的细节。对于每一种特性，向标记中添加一个字母： 

·         -1_34 
版本标记：完整的Boost发布号，下划线代替点。例如，1.31.1版本将被标记为“-1_31_1”。

·         .lib 
扩展名：取决于操作系统。在大多数unix平台上，.a是静态库，.so是共享库。在Windows上，.dll表示共享库，.lib是静态或导入库。

下表是对Regex库编译后的文件名：

需要注意的是，链接时，所使用的Regex库文件名必须和编译选项匹配，否则会造成如下链接错误：

LINK : warning LNK4098: defaultlib '×××××' conflicts with use of other libs; use /NODEFAULTLIB:library

命令解析

将下面内容在.txt文件中保存后，将文件名的“.txt”改成“.bat”，运行即可。

@echo off

for /r %%a in (.) do if exist %%a\.svn rd /s/q %%a\.svn

pause

@echo on

---------------------------------------------------------------------------------------------------

for /r %%a in (.) do if exist %%a\.svn rd /s/q %%a\.svn 这个语句句主要的作用是删除该bat所在的当前目录及其子目录中的所有.svn目录

该语句的解释如下：

首先判断是否存在.svn目录，如果存在，不需用户确认就将其删除；否则进行下次循环。

for /r %%a in (.) do -----循环判断指定目录及其子目录

if exist %%a\.svn rd /s/q %%a\.svn -----这是循环体

If exist %%a\.svn------判断是否存在.svn文件夹

rd /s/q %%a\.svn ------不用确认，直接删除.svn文件夹

首先，我们要知道支持的字符编码有哪些，这个可以用-l参数得到（List known coded character sets）。

格式：iconv -l

其次，是怎样转换，如下所示：

格式：iconv -f from-encoding -t to-encoding inputfile

上面的调用方式，会把输出打印在屏幕上，如果要输出到文件，可以像下面这样

格式：iconv -f from-encoding -t to-encoding inputfile -o outputfile

其实最后这些设置都保存在C:\Documents and Settings\用户名\.gitconfig 文件下（windows）

查看帮助： git help command

git init

git add *.txt //添加所有txt文件
git add README //添加单个文件
git add . //添加所有文件包括子目录，但不包括空目录

add命令是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等）注意每次修改后都要重新add,不然就会提交之前add时的版本。

git add -i //进入交互式add
git add -p //直接进入补丁模式，可以暂存修改的一部分。

git commit -m “initial project version”
git commit -m “something” someFile //提交指定文件
git commit -C HEAD -a —amend //复用HEAD留言，增补提交（修改小错误，而不增加提交记录，掩盖自己的小马虎）

-m “提交的说明”
-a 动把所有已经跟踪过的文件暂存,并提交.(工作目录中修改过的文件都提交到版本库，不需一个一个手动add了)
—amend 增补提交
-C 复用指定提交的提交留言
-c 打开编辑器在已有的提交基础上编辑修改

e.g 修改最后一次提交:

如果没有修改就相当于更改提交说明,上边3个命令得到一个提交.

所有人都需要忽略的文件要写在.gitignore文件里，而只有自己的个人偏好需要忽略的文件要写在.git/info/exclude文件中

语法：

git diff // 比较工作目录与缓存区的区别
git diff —cached 或者 git diff —staged //缓存区与版本库里的区别
git diff HEAD //三者的区别

请注意，单单 git diff 不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存了所有更新过的文件后，运行 git diff 后却什么也没有，就是这个原因。
git diff 18f822e //18f822e这个版本与当前目录的区别

git diff aaaaa..bbbbb //比较aaaaa与bbbbb之间差别
git diff —stat可以统计数据，比较特别的命令

git mv file_from file_to //改名或移动

其实，运行 git mv 就相当于运行了下面三条命令：

$ mv README.txt README
$ git rm README.txt
$ git add README

必须调用 git rm 文件名 //从暂存区移除,并且文件也被删除

如果只是手工删除了文件,运行git status时会出现

此时必须再运行 git rm 文件名,才会在提交时候不再纳入版本管理.
如果删除之前修改过并且已经add到缓存区了的话,则必须强制删除 -f

另外一种情况是，我们想把文件从Git仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆.a编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用 —cached 选项即可：

git status

git log

这时“j”向下浏览，“k”向上浏览，“q”退出

git log —pretty=oneline //一行显示
—pretty=“%h %s” //以各种格式输出

git log –p -2 //-p显示每次提交的内容差异 -2表示最近2次更改

git log —since “5 hours”
—since “3 hours”
—since “1 minute”
—before =“2008-10.01”

git log 27j34j3j..03u43u23 //最老版本..最新版本（不包括起点只包括终点）
git log 34j4j4..HEAD
git log fhfs8fh.. //省略HEAD
git log “HEAD^^”..“HEAD^” //windows必须加引号表示回溯上一个提交
git log -1 HEAD~1 //相当于git log -1 HEAD^

git blame hello.html //你也可以用"-L"参数在命令(blame)中指定开始和结束行:
git blame -L 12,+10 hello.html //12到22行
blame还可以跟踪内容复制，文件复制，略，见版本控制之道 79页

git checkout head 文件名 //撤销暂存区的修改 
git checkout head readme.txt todo.txt
git checkout head *.txt
git checkout head . //撤销所有

git revert HEAD //创建一个反向的新提交抵消原来的提交改动
如果需要反转多个，必须从最后的开始反转, 加 -n可以不马上提交，之后一起提交。
git revert -n HEAD
git revert -n 54efhds
git commit -m “revert head and 54efhds”

git reset —hard HEAD //所有未提交的内容清空，这会让"git diff" 和"git diff —cached"命令的显示法都变为空
git reset —soft HEAD //复位版本库，暂存差异，便于提交中发现错误需要更改时有用（例如私人密码放到里边了）

git branch RB_1.0（建立分支不会自动切换过去）

git checkout RB_1.0（切换到RB_1.0分支）

git checkout -b RB_1.0（简化上边2步操作）

git branch -d RB_1.0

git branch RB_1.0 master
git branch RB_1.0 6fe57de0
git branch Rb_1.01 1.0

git branch -r //显示远程分支
git branch -a //列出所有分支

git branch -m master mymaster
-M 大写M会覆盖同名的分支

直接合并：
git merge 想合并到当前分支的源分支名
git merge —no-commit 分支 //合并但不提交

压合合并：将分支压合成一条commit记录，并合并过来
git merge —squash 某bug分支
git commit -m “修复某bug”

拣选合并：只合并一个提交
git cherry-pick 321d76f
如果需要连续拣选，就需要加 -n参数
然后再git commit ，但不要加-m参数，编辑器就会使用刚拣选的提交留言作为现在的留言。

git tag

git tag 1.0 //在当前分支最后一次提交创建标签
git tag 1.0 RB_1.0 //基于RB_1.0分支的最新踢脚创建标签
git tag 1.0 ae468d8kt //为某次提交创建标签

git checkout 1.0 //检出标签与检出分支一样操作，但检出标签后用git branch查看本地分支会发现你现在不再任何分支上
这时你不应该修改，而应该立即基于此标签创建一个分支
git checkout -b from-1.0

1）git rebase RB_1.01 //也许修改过一个bug，希望新版本变基到RB_1.01分支上
2）手动解决冲突 //如果解决不了直接git rebase -abort来跳过特定提交或完全放弃变基
3）git add xxx.html //冲突解决
4）git rebase —continue

//—onto参数可以改写历史抹掉中间的参数，将倒数第一个参数变基到倒数第3个参数，为防止出错建议在试验性分支上先试验。

rebase -i 可以排序历史记录，多个提交合并为1个，一个提交分解成多个提交 ，
详见版本控制之道p86 ，需要编辑器支持，windows记事本不行

git clone git://github.com/schacon/grit.git //从现有仓库克隆
git clone git://github.com/schacon/grit.git mygrit //换名,唯一区别就是新建的目录成了mygrit,其他都一样

git remote add pb git://github.com/paulboone/ticgit.git
clone会默认添加origin仓库，如果原本用git init创建的版本库，后来又想提交到远程版本库，就可以用下边的办法
git remote add origin git@example.com:/xxxxxx

git remote -v //查看远程仓库,默认clone后,应该有一个origin仓库,-v显示对应的clone地址
git remote show origin //查看远程仓库信息

git remote rename pb paul
git remote rm paul

现在pb/master可以在本地访问了,你可以合并到自己的某个分支,或者切换到这个分支看看有什么有趣的更新

git pull 抓取数据合并到工作目录中当前分支

git push [remote-name] [branch-name] //默认为 git push origin master

git push origin serverfix //推送分支，其实是下边一句的简化,提取我的 serverfix 并更新到远程仓库的 serverfix

git push origin serverfix:serferfix

git push origin :serverfix //这个语法用于删除,只要把分号前留空

git gc //垃圾回收，每隔一段时间例如一个月运行一次可以减少磁盘占用空间。
git reflog //最后的保障,列出误删的东东
git bisect //二分查找，版本控制之道p124页，略

git archive —format=格式 —prefix=目录/ 版本>压缩包.zip
git archive —format=zip head>test.zip
git archive —format=tar —prefix=mysite-1.0/ 1.0 | gzip>mysite-1.0.tar.gz
git archive —format=zip —prefix=mysite-1.0/ 1.0 >mysie-1.0.zip

实现中主要用到listNode、list、listIter三个结构，listNode代表链表中的每个节点，list指向整个链表，listIter是为了迭代访问整个list，内部其实就是个listNode指针。

listNode提供的prev、next指针将整个list链接成一个双向链表，保存的值是void *类型，对值的复制、释放、匹配操作是用在list中注册的三个函数指针dup、free、match完成的。

在list结构中，除提供对listNode中的值进行操作的三个函数指针外，还提供了head、tail指针，以指向list的头部和尾部。另外list的len保存了整个list的长度，方便对list是否为空的判断(纯属多余吧)。

listIter是为了遍历list，可以从头部、尾部开始遍历。用法可用如下伪代码表示：

iter=listGetIterotr(list, <direction>); while ((node=listNext(iter)) !=NULL) { 	DoSomethingWith(listNodeValue(node)); }

另外注意：在提供的增加、删除节点的api（listAddNodeHead、listAddNodeTail、listDelNode）中，并没有分配、释放节点 内部的value所用内存，需要调用者自己分配或者释放value所占的内存（除了分配和释放节点本身的内存外）。

乍一看没有提供修改某个节点的值的方法，但是由于listSearchKey、listIndex等方法返回了节点指针，故可以直接修改节点的value。

你可以通过telnet或者redis_cli、利用lib库发送请求给redis server。前者的是一种裸协议的请求发送到服务端，而后两者会对键入的请求进行协议组装帮助更好的解析（常见的是长度放到前头，还有添加阿协议类型）。

Requests格式

*参数的个数 CRLF $第一个参数的长度CRLF 第一个参数CRLF ... $第N个参数的长度CRLF 第N个参数CRLF

例如在redis_cli里键入get a，经过协议组装后的请求为

2\r\n$3\r\nget\r\n$1\r\na\r\n

下面这个图涵盖了接收request，处理请求，调用函数，发送reply的过程。

redis的网络事件库，我们在前面的文章已经讲过，readQueryFromClient先从fd中读取数据，先存储在c->querybuf里(networking.c 823)。接下来函数processInputBuffer来解析querybuf，上面说过如果是telnet发送的裸协议数据是没有*打头的表示参数个数的辅助信息，针对telnet的数据跳到processInlineBuffer函数，而其他则通过函数processMultibulkBuffer。
这两个函数的作用一样，解析c->querybuf的字符串，分解成多参数到c->argc和c->argv里面，argc表示参数的个数，argv是个redis_object的指针数组，每个指针指向一个redis_object, object的ptr里存储具体的内容，对于”get a“的请求转化后，argc就是2，argv就是

(gdb) p (char*)(*c->argv[0])->ptr $28 = 0x80ea5ec "get" (gdb) p (char*)(*c->argv[1])->ptr $26 = 0x80e9fc4 "a"

协议解析后就执行命令。processCommand首先调用lookupCommand找到get对应的函数。在redis server 启动的时候会调用populateCommandTable函数（redis.c 830）把readonlyCommandTable数组转化成一个hash table（server.commands），lookupCommand就是一个简单的hash取值过程，通过key（get）找到相应的命令函数指针getCommand（ t_string.c 437）。
getCommand比较简单，通过另一个全局的server.db这个hash table来查找key，并返回redis object，然后通过addReplyBulk函数返回结果。

下面介绍一下reply协议。
bulk replies是以$打头消息体，格式$值长度\r\n值\r\n，一般的get命令返回的结果就是这种个格式。

redis>get aaa $3\r\nbbb\r\n

对应的的处理函数addReplyBulk

addReplyBulkLen(c,obj); addReply(c,obj); addReply(c,shared.crlf);

error messag是以-ERR 打头的消息体，后面跟着出错的信息，以\r\n结尾，针对命令出错。

redis>d -ERR unknown command 'd'\r\n

处理的函数是addReplyError

addReplyString(c,"-ERR ",5); addReplyString(c,s,len); addReplyString(c,"\r\n",2);

integer reply 是以:打头，后面跟着数字和\r\n。

redis>incr a :2\r\n

处理函数是

addReply(c,shared.colon); addReply(c,o); addReply(c,shared.crlf);

status reply以+打头，后面直接跟状态内容和\r\n

redis>ping +PONG\r\n

这里要注意reply经过协议加工后，都会先保存在c->buf里，c->bufpos表示buf的长度。待到事件分离器转到写出操作（sendReplyToClient）的时候，就把c->buf的内容写入到fd里，c->sentlen表示写出长度。当c->sentlen=c->bufpos才算写完。

还有一种Multi-bulk replies，lrange、hgetall这类函数通常需要返回多个值，消息结构与请求的格式一模一样。相关的函数是setDeferredMultiBulkLength。临时数据存储在链表c->reply里，处理方式同其他的协议格式。

全量的原理就是遍历里所有的DB，在每个bucket，读取链表的key和value并写入dump.rdb文件（rdb.c 405）。

save命令直接调度rdbSave函数，这会阻塞主线程的工作，通常我们使用bgsave。

bgsave命令调度rdbSaveBackground函数启动了一个子进程然后调度了rdbSave函数，子进程的退出状态由 serverCron的backgroundSaveDoneHandler来判断，这个在复制这篇文章里讲到过，这里就不罗嗦了。

除了直接的save、bgsave命令之外，还有几个地方还调用到rdbSaveBackground和rdbSave函数。

shutdown：redis关闭时需要对数据持久化，保证重启后数据一致性，会调用rdbSave()。

flushallCommand：清空redis数据后，如果不做立即执行一个rdbSave()，出现crash后，可能会载入含有老数据的dump.rdb。

void flushallCommand(redisClient *c) {   touchWatchedKeysOnFlush(-1);   server.dirty += emptyDb();      // 清空数据   addReply(c,shared.ok);   if (server.bgsavechildpid != -1) {     kill(server.bgsavechildpid,SIGKILL);     rdbRemoveTempFile(server.bgsavechildpid);   }   rdbSave(server.dbfilename);    //没有数据的dump.db   server.dirty++; }

sync：当master接收到slave发来的该命令的时候，会执行rdbSaveBackground，这个以前也有提过。

数据发生变化：在多少秒内出现了多少次变化则触发一次bgsave，这个可以在conf里配置

for (j = 0; j < server.saveparamslen; j++) {   struct saveparam *sp = server.saveparams+j;    if (server.dirty >= sp->changes && now-server.lastsave > sp->seconds) {      rdbSaveBackground(server.dbfilename);      break;   } }

增量备份就是aof，原理有点类似redo log。每次执行命令后如出现数据变化，会调用feedAppendOnlyFile，把数据写到server.aofbuf里。

void call(redisClient *c, struct redisCommand *cmd) {   long long dirty;   dirty = server.dirty;   cmd->proc(c);        //执行命令   dirty = server.dirty-dirty;   if (server.appendonly && dirty)     feedAppendOnlyFile(cmd,c->db->id,c->argv,c->argc);

待到下次循环的before_sleep函数会通过flushAppendOnlyFile函数把server.aofbuf里的数据write到append file里。
可以在redis.conf里配置每次write到append file后从page cache刷新到disk的规律。

# appendfsync always appendfsync everysec # appendfsync no

参数的原理MySQL的innodb_flush_log_at_trx_commit一样，是个比较影响io的一个参数，需要在高性能和不丢数据之间做tradeoff。软件的优化就是tradeoff的过程，没有银弹。

一个疑问先写到server.aofbuf，然后再写到数据文件，过程中如果crash会不会丢数据呢？

答案是不会，为何？我们来看函数执行的步骤：

call() feedAppendOnlyFile() 下一次循环 beforeSleep()-->flushAppendOnlyFile() aeMain()--->sendReplyToClient()

只有执行完了flush之后才会通知客户端数据写成功了，所以如果在feed和flush之间crash，客户接会因为进程退出接受到一个fin包，也就是一个错误的返回，所以数据并没有丢，只是执行出了错。

redis crash后，重启除了利用rdb重新载入数据外，还会读取append file(redis.c 1561)加载镜像之后的数据。

激活aof，可以在redis.conf配置文件里设置

appendonly yes

也可以通过config命令在运行态启动aof

cofig set appendonly yes

aof最大的问题就是随着时间append file会变的很大，所以我们需要bgrewriteaof命令重新整理文件，只保留最新的kv数据。

下面这个根据图形来描述一下aof的全过程，绿色的为aof.c里的函数，顺序从左到右。

启动appendly，或者config set appendonly yes 都会触发函数rewriteAppendOnlyFileBackground，bgrewriteaof也调用该函数。

实际最后调用的函数是rewriteAppendOnlyFile,这个函数与rdbSave和类似。保存全库的kv数据。

在子进程做快照的过程中，kv的变化是先写到aofbuf里。如果存在bgrewritechildpid进程，变化数据还要写到server.bgrewritebuf里（aof.c 177）。
等子进程完成快照退出之时，由backgroundRewriteDoneHandler函数再把bgrwritebuf和全镜像两部分数据进行合并（aof.c 673）。

合并后的aof文件才是最新的全库的镜像数据。

slaveof masterip port

在slave端键入命令之后，就开启了从master到slave的复制。一个master可以有多个slave，master有变化的时候会主动的把命令传播给每个slave。slave同时可以作为其他的slave的master，前提条件是这个slave已经处于稳定状态（REDIS_REPL_CONNECTED）。slave在复制的开始阶段处于阻塞状态（sync_readline）无法对外提供服务。

数据的有向图会让redis的运维很有搞头。

slaveof no one

从slave状态的转换回master状态，切断与原master的数据同步。

下面根据图形来描述一个复制全过程。

复制的顺序是从左到右。绿色的过程表示replstate复制状态的变迁，复制相关的函数主要在src/replication.c里，红色为master的复制函数，蓝色的为slave使用的复制函数。

slave端接收到客户端的slaveof masterip ort命令之后，根据readonlyCommandTable找到对应的函数为slaveofCommand。slaveofCommand会保存masterip，masterport，并把server.replstate改成REDIS_REPL_CONNECT，然后返回给客户端OK。

slave端主线程在已经注册时间事件serverConn（redis.c 518）里执行replicationCron（redis.c 646）来开始与master的连接。调用syncWithMaster()开始与master的通信。经过校验之后，会发送一个SYNC command给master端，然后打开一个临时文件用于存储接下来master发过来的rdb文件数据。再添加一个文件事件注册readSyncBulkPayload函数，这个就是接收rdb文件的数据的函数，然后修改状态为REDIS_REPL_TRANSFER。

master接收到SYNC command后，跳转到syncCommand函数（replication.c 556）。syncCommand会调度rdbSaveBackground函数，启动一个子进程做一个全库的持久化rdb文件，并把状态改为REDIS_REPL_WAIT_BGSAVE_END。

master的主线程的serverCron会等待做持久化的子进程的退出，并判断退出的状态是否是正常。

if ((pid = wait3(&statloc,WNOHANG,NULL)) != 0) { if (pid == server.bgsavechildpid) { backgroundSaveDoneHandler(statloc); } else { ....

如果子进程正常退出，会转到backgroundSaveDoneHandler函数。backgroundSaveDoneHandler 处理每次rdbSaveBackground成功后的收尾工作，并打开刚刚产生的rdb文件。然后注册一个sendBulkToSlave函数用于发送rdb文件，状态切换至REDIS_REPL_SEND_BULK。

sendBulkToSlave作用就是根据上面打开的rdb文件，读取并发送到slave端，当文件全部发送完毕之后修改状态为REDIS_REPL_ONLINE。

我们回到slave，上面讲到slave通过readSyncBulkPayload接收rdb数据，接收完整个rdb文件后，会清空整个数据库emptyDb()(replication.c 374)。然后就通过rdbLoad函数载入接收到的rdb文件，于是slave和master数据就一致了，再把状态修改为REDIS_REPL_CONNECTED。

接下来就是master和slave之间增量的传递的增量数据，另外slave和master在应用层有心跳检测（replication.c 543），和超时退出（replication.c 511）。

最后再给出一个replstate状态图

slave端复制状态

REDIS_REPL_NONE：未复制的状态

REDIS_REPL_CONNECT：已经接收到slaveof命令，但未发出sync命令给master

REDIS_REPL_TRANSFER：已经发出sync，但还没接收完rdb文件

REDIS_REPL_CONNECTED：已经接收完rdb文件，开始增量接收复制内容

maste端redis_client的复制状态

REDIS_REPL_WAIT_BGSAVE_START：bgsave被抢占，等待bgsave为其持久化进行工作。

REDIS_REPL_WAIT_BGSAVE_END：等待bgsave持久化rdb文件。

REDIS_REPL_SEND_BULK：rdb文件已经生成。开始拷贝给slave。

REDIS_REPL_ONLINE：rdb拷贝完毕，开始增量复制。

另外在syncCommand函数里有几种可能性

bgsave进程未启动，则启动。

bsave已启动，且已经存在另外的一个slave连接，已经由这个连接开启了bgsave，则等待bgsave完毕，共享这次的持久化。

bsave已启动，但不是由slave连接所启动的，则等待下次bgsave的退出。在updateSlavesWaitingBgsave函数里再次启动bgsave进程。

update:

dict 包含了2个dictht hashtable ht[0], ht[1]。
client版本的dict是没有dictht的概念。加入dictht的概念存在2个ht的目的是为了在rehash的时候可以平滑的迁移bucket里的数据，而不像client的dict要把老的hash table里的一次性的全部数据迁移到新的hash table，这在造成一个密集型的操作，在业务高峰期不可取。

ht是hashtable的简称，实际上是一个指针数组，数组的个数由dictht->size决定，是DICT_HT_INITIAL_SIZE的整数倍。每个元素（bucket）指向一个dictEntry的单链表来解决hash的conflict。查询某个key，需要先hash，定位到bucket,再通过链表遍历。

key经过hash函数后，与dictht->sizemask求与均分到ht的每个bucket上。dictht->used表示这个ht里包含的key的个数，也就是dictEntry的个数，每次dictAdd成功+1。链表的加入为头指针的方法加入，这样dictAdd更加的方便。

随着key不断的添加，bucket下的单链表越来越长，查找、删除效率越来越低，需要对ht进行expand，增加bucket个数，让链表的长度减少。bucket数量的增多，原有bucket的key需要迁移到新的bucket上，于是有了rehash的这个过程。

ht[1]就是为了rehash而产生，新的ht size是ht[0]的两倍2， 随着dictAdd，dictFind函数的调用，ht[0]的每个bucket会rehash加入到ht[1]里。dict->rehashidx 是ht[0] 需要rehash就是迁移到ht[1]的bucket的索引，从0开始直到ht->used==0。
rehash除了每次伴随dictAdd，dcitFind而迁移一个bucket的所有dictEntry，还有一种一次hash100个bucket，直到消耗了某个时间点为止的做法。

rehash的步骤：
拿到一个bucket， 遍历这个链表的每个kv，对key进行hash然后于sizemask求与，定位ht[1]的新bucket位置，
加入到链表，迁移后ht[0].used–，ht[1].used++。
直到ht[0].used=0，释放ht[0]的table，再赋值ht[0]= ht[1]，再把则ht[1]reset。

rehash的期间：
由于ht[1]是ht[0]size的2倍，每次dictAdd的时候都会rehash一次，不会出现后ht[1] 满了，而ht[0]还有数据的事情。
查询会先查ht[0]再查询ht[1]，在rehash的过程中，不会出现再次expand。
新的key加到ht[1]。

expand的条件：
table的位置已经满了，糟糕的hash函数造成的skrew导致永远不会expand。
key的个数除以table的大小，超过了dict_force_resize_ratio。

事件库仅仅包括ae.c、ae.h，还有3个不同的多路复用（本文仅描述epoll）的wrapper文件，事件库封装了框架调用的主循环函数，暴露了时间、文件事件注册和销毁函数，典型的依赖反转模式。
网络操作都在networking.c里，封装了常见的socket操作。

我们从redis启动的main函数开始，从用户发出连接键入命令开始遍历网络事件库所涉及的函数，unix套接口相关函数不表。

首先对几个最常用对象进行解释。

//redis启动的时候（init_server()）会创建的一个全局使用的事件循环结构 typedef struct aeEventLoop { int maxfd;		//仅仅是select 使用 long long timeEventNextId; aeFileEvent events[AE_SETSIZE]; //用于保存epoll需要关注的文件事件的fd、触发条件、注册函数。 aeFiredEvent fired[AE_SETSIZE]; //epoll_wait之后获得可读或者可写的fd数组，通过aeFiredEvent->fd再定位到events。 aeTimeEvent *timeEventHead;	//以链表形式保存多个时间事件，每隔一段时间机会触发注册的函数。 int stop; void *apidata;			//每种多路复用方法的使用的私有变量，例如epoll就是epfd和一个事件数组;而select是保存rset、wset。 aeBeforeSleepProc *beforesleep;	// sleep之前调用的函数，有些事情是每次循环必须做的，并非文件、时间事件。 } aeEventLoop;  //文件可读写事件 typedef struct aeFileEvent { int mask; 			//触发条件：读、写 aeFileProc *rfileProc;		//当fd可读时执行的事件（accept，read） aeFileProc *wfileProc;		//当fd可写时执行的事件（write） void *clientData;               //caller 传入的数据指针 } aeFileEvent;  //超时时间事件 typedef struct aeTimeEvent { long long id; /* time event identifier. */ long when_sec; /* seconds */ long when_ms; /* milliseconds */ aeTimeProc *timeProc;		//当出现超时的时候所执行的事件 aeEventFinalizerProc *finalizerProc; void *clientData;                //caller传入的数据指针 struct aeTimeEvent *next;	//单链表指向下一个时间事件 } aeTimeEvent;  //从epoll_wait或者select返回的，已经触发的文件事件 typedef struct aeFiredEvent { int fd; int mask; } aeFiredEvent;

我们来模拟redis server 启动和用户键入命令的过程，先上图。

好吧，从main函数开始吧。

// src/redis.c 853 server.el = aeCreateEventLoop();

创建一个aeEventLoop结构体，成员apidata指向一个aeApiState对象，如果使用epoll，fd是由epoll_create创建的全局epoll fd ，events[] 用于保存epoll_wait返回的事件组。

// src/redis.c 866 server.ipfd = anetTcpServer(server.neterr,server.port,server.bindaddr);

创建监听。

//   src/redis.c 903 aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL);

注册一个时间事件serverCron，作用以后再讲。

 //   src/redis.c 906 aeCreateFileEvent(server.el,server.ipfd,AE_READABLE,  acceptTcpHandler,NULL)

为监听fd的注册一个文件事件，首先把listenfd和触发条件epoll_ctl加入到全局的epoll fd进行监控。再以fd作为文件事件event数组index定位，mask填入只读，rfileProc填入acceptTcpHandler函数。

// src/redis.c 1571 aeSetBeforeSleepProc(server.el,beforeSleep);

aeEventLoop注册一个beforeSleep函数，这个函数在主循环里每次会被调用，作用以后再讲。

// src/ redis.c 1572 aeMain()

网络事件库的核心循环函数。

// src/ae.c  379 aeCreateLoop->beforesleep()

就是上面注册的beforeSleep函数。

// src/ae.c 275 aeProcessEvents(eventLoop, AE_ALL_EVENTS);

先调度aeApiPoll，用epoll_wait处理文件事件，返回的fd和触发条件先存储在eventLoop->fired[]里，然后根据fired[]每个事件的的fd，定位到events，根据触发条件调用已经注册的事件。

文件事件处理完毕后，接下来就是处理超时时间事件，这里不表。

假如有个用户连接上redis，则从redis servere就从上面的aeApiPoll的poll_wait返回，产生的只读事件会调度上面注册了acceptTcpHandler函数。

// src/networking.c 390 acceptTcpHandler(eventLoop, fd, NULL, AE_READABLE)

accept返回产生了一个新连接的fd（这里省略了很多步骤），需要从新的连接读取数据，于是为这个fd注册可读事件。

// src/networking.c 20 aeCreateFileEvent(server.el,fd,AE_READABLE,  readQueryFromClient, c)

于是调用了aeCreateFileEvent 为只读事件注册, 这里的步骤和上面的listen fd 一样。用epoll_ctl将fd加入到epoll fd里等待下次epoll_wait，再注册触发条件和readQueyFromClient函数，接着aeMain()继续执行等待用户的数据。

假如用户在这个连接键入redis命令例如：set foo bar，redis server端将会从aeApiPoll的epoll_wait返回，和accept一样的处理方式。返回的fd填入到fired[]数组，通过fired[fd]->fd找到是哪个文件事件，找到events[fd]->rfielProc这个函数，就是上面注册的readQueyFromClient 函数。

//  src/networking.c 816 readQueyFromClient(server.el, fd, NULL, AE_READABLE)

这个函数首先会执行read从tcp buffer读取用户键入的命令（非阻塞io），然后处理buffer，找到对应的command（lookupCommand），接下来执行这个command（call(c,cmd)），命令执行完毕需要返回结果的时候，会再次注册一个文件事件

// src/networking.c  71 aeCreateFileEvent(server.el, c->fd, AE_WRITABLE, sendReplyToClient, c)

这样下次循环epoll_wait的时候就发现这个fd可写，于是就会执行sendReplyToClient，讲结果发送给client。

redis的这个网络事件库是比较标准的网络框架的模式，实现的功能不算多但够用。

流媒体指的是在网络中使用流技术传输的连续时基媒体，其特点是在播放前不需要下载整个文件，而是采用边下载边播放的方式，它是视频会议、IP电话等应用场合的技术基础。RTP是进行实时流媒体传输的标准协议和关键技术，本文介绍如何在Linux下利用JRTPLIB进行实时流媒体编程。

一、流媒体简介
     随着Internet的日益普及，在网络上传输的数据已经不再局限于文字和图形，而是逐渐向声音和视频等多媒体格式过渡。目前在网络上传输音频/视频（Audio/Video，简称A/V）等多媒体文件时，基本上只有下载和流式传输两种选择。通常说来，A/V文件占据的存储空间都比较大，在带宽受限的网络环境中下载可能要耗费数分钟甚至数小时，所以这种处理方法的延迟很大。如果换用流式传输的话，声音、影像、动画等多媒体文件将由专门的流媒体服务器负责向用户连续、实时地发送，这样用户可以不必等到整个文件全部下载完毕，而只需要经过几秒钟的启动延时就可以了，当这些多媒体数据在客户机上播放时，文件的剩余部分将继续从流媒体服务器下载。
       流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。由于受网络带宽、计算机处理能力和协议规范等方面的限制，要想从Internet上下载大量的音频和视频数据，无论从下载时间和存储空间上来讲都是不太现实的，而流媒体技术的出现则很好地解决了这一难题。目前实现流媒体传输主要有两种方法：顺序流（progressive streaming）传输和实时流（realtime streaming）传输，它们分别适合于不同的应用场合。

顺序流传输 
      顺序流传输采用顺序下载的方式进行传输，在下载的同时用户可以在线回放多媒体数据，但给定时刻只能观看已经下载的部分，不能跳到尚未下载的部分，也不能在传输期间根据网络状况对下载速度进行调整。由于标准的HTTP服务器就可以发送这种形式的流媒体，而不需要其他特殊协议的支持，因此也常常被称作HTTP流式传输。顺序流式传输比较适合于高质量的多媒体片段，如片头、片尾或者广告等。

实时流传输 
      实时流式传输保证媒体信号带宽能够与当前网络状况相匹配，从而使得流媒体数据总是被实时地传送，因此特别适合于现场事件。实时流传输支持随机访问，即用户可以通过快进或者后退操作来观看前面或者后面的内容。从理论上讲，实时流媒体一经播放就不会停顿，但事实上仍有可能发生周期性的暂停现象，尤其是在网络状况恶化时更是如此。与顺序流传输不同的是，实时流传输需要用到特定的流媒体服务器，而且还需要特定网络协议的支持。

另外，RFC3550可以看作是RFC1889的升级文档，只看RFC3550即可。

• RTP：实时传输协议（Real-time Transport Protocol）
  • RTP/RTCP是实际传输数据的协议
  • RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server
  • 整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）
• RTSP：实时流协议（Real Time Streaming Protocol，RTSP）
  • RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用
  • RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等
• RTCP：
  • RTP/RTCP是实际传输数据的协议
  • RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议

以下是每个协议的概要介绍：

一、RTP数据协议 
    RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示：

    其中比较重要的几个域及其意义如下： 

• CSRC记数（CC）：表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。 
• 负载类型（PT）：标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。 
• 序列号：用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。 
• 时间戳：记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。

    从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的，如图2所示：

二、RTCP控制协议 
    RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。

    RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：