博客园_代震军BLOG

开源ImageFilter库：新增7类滤镜，支持12种图片效果

2012-05-21T05:41:00Z

经过近三天的开发，在原有40套滤镜(v0.1)基本上，又新增实现了7类滤镜(v0.2)，通过组合使用，可直接做出12种图片效果。相信总有几款适合您，哈哈。

下面是图片效果：

LomoFilter

PaintBorderFilter-green

PaintBorderFilter-blue

PaintBorderFilter-yellow

SceneFilter-1

SceneFilter-2

SceneFilter-3

SceneFilter-4

ComicFilter

FilmFilter

FocusFilter

CleanGlassFilter

参考链接：Android, WindowsPhone7, IOS ,vc2010平台40多套图片滤镜开源

源码下载：http://www.cnblogs.com/daizhj/archive/2012/05/21/2511508.html

   https://github.com/daizhenjun/ImageFilterC  C++ for ios
   https://github.com/daizhenjun/ImageFilterForWindowsPhone Windows Phone7
   https://github.com/daizhenjun/ImageFilterForAndroid Android 2.1版本及以后

   原文链接:http://www.cnblogs.com/daizhj/archive/2012/05/21/2511508.html
   作者: daizhj, 代震军
   微博: http://weibo.com/daizhj
   Tags: imagefilter, android,windowsphone,ios, vs2010,c++, java,c#

本文链接

Android, WindowsPhone7, IOS ,vc2010平台40多套图片滤镜开源

2012-05-15T05:54:00Z

历经三个多月开发，终于完成了这三个库的编码工作。用到的开发语言主要有使用了C++（含部分Object-c）,JAVA,C#。经过检测，目前已正式投入到生产环境中。

为了实现三种语言一种命名方式，我采用了相同的类名，接口，namespace(package)。可以说只要熟悉了其中一个平台的代码，就可以很顺利的写出另外两个平台的滤镜代码（当然我后续还会加入更多的滤镜效果）。

该库基于LGPL协议，也就是说大家可以将其免费用于自己公司的项目及产品中（包括商业项目）。

当然如果大家用后觉得还可以的话，可以私下洽谈合作事宜.（包括商业方面, EMAIL: daizhj617595@126.com），呵呵！

下面是使用这三个滤镜类库所实现的滤镜效果。

InvertFilter

AutoLevelFilter

RadialDistortionFilter

BannerFilter(20, true)

BannerFilter(20, false)

BigBrotherFilter

BlackWhiteFilter

ColorQuantizeFilter

ConvolutionFilter

BrickFilter

BlockPrintFilter

EdgeFilter

FeatherFilter

GaussianBlurFilter

GradientMapFilter

HistogramEqualFilter

LightFilter

MistFilter

MonitorFilter

MosaicFilter

NeonFilter

NightVisionFilter

NoiseFilter

OilPaintFilter

OldPhotoFilter

PixelateFilter

RainBowFilter

RectMatrixFilter

ReflectionFilter(false)

ReflectionFilter(true)

ReliefFilter

SaturationModifyFilter

SepiaFilter

SmashColorFilter

ThresholdFilter

TintFilter

VignetteFilter

VintageFilter

WaterWaveFilter

XRadiationFilter

源码下载：

   原文链接:http://www.cnblogs.com/daizhj/archive/2012/05/15/2501406.html
   作者: daizhj, 代震军
   微博: http://weibo.com/daizhj
   Tags: imagefilter, android,windowsphone,ios, vs2010,c++, java,c#

本文链接

Discuz!NT中的LLServer架构设计

2011-08-26T03:13:00Z

在开发LLServer的同时，我一直在跟进测试企业版的相应LLServer客户端，目前这部分代码已测试完毕并提交的Discuz!NT产品中，会跟随最新的源码包一并发布。本文主要是介绍一下产品中引入LLServer的架构思路。

在Discuz!NT的企业版产品中，使用了Memcached,Redis这两个软件来提供分布式缓存服务（两者任选其一）。现有又有了LLServer,它不仅提供了KEY/VALUE缓存，还包括持久化存储部分。这样，用户可以有更多大的选择余地。

下面是Discuz!NT的企业版分布式缓存中一个架构图(DNTCache用于包含调用cacheStrategy)：

我们通过配置相应的config文件来决定使用那种类型的缓存服务。当然其也有一个优先顺序，即：memcached, redis, llserver。这可以参照最新版的DNTCache.cs文件（位于Discuz.Cache项目下），部分代码参见如下：

/// <summary>
/// 构造函数
/// </summary>
private DNTCache()
{
    if (MemCachedConfigs.GetConfig() != null && MemCachedConfigs.GetConfig().ApplyMemCached)
        applyMemCached = true;
    if (RedisConfigs.GetConfig() != null && RedisConfigs.GetConfig().ApplyRedis)
        applyRedis = true;
    if (LLServerConfigs.GetConfig() != null && LLServerConfigs.GetConfig().ApplyLLServer)
        applyLLServer = true;

    if (applyMemCached || applyRedis || applyLLServer)
    {
        try
        {
            string cacheStratetyName;
            if(applyMemCached)
                cacheStratetyName = "MemCachedStrategy";
            else if(applyRedis)
                cacheStratetyName = "RedisStrategy";
            else
                cacheStratetyName = "LLStrategy";

            cs = cachedStrategy = (ICacheStrategy)Activator.CreateInstance(Type.GetType("Discuz.EntLib." + cacheStratetyName + ", Discuz.EntLib", false, true));
        }
        catch
        {
            throw new Exception("请检查Discuz.EntLib.dll文件是否被放置在bin目录下并配置正确");
        }
    }
    else
    {
        cs = new DefaultCacheStrategy();
        if (rootXml.HasChildNodes)
            rootXml.RemoveAll();

        objectXmlMap = rootXml.CreateElement("Cache");
        //建立内部XML文档.
        rootXml.AppendChild(objectXmlMap);
    }

}

当memcached.config及redis.config文件的Apply..选项为false时，这时如启用llserver.config文件的如下节点，即可启动llserver。

注:有关llserver的安装使用信息请参见如下链接：
http://www.cnblogs.com/daizhj/archive/2011/08/23/2150422.html

下面介绍一下我们企业版中LLSERVER的客户端的设计思路。熟悉我们产品的朋友知道我们的缓存设计基于stratety模式，之前的memcached,redis都有相应的策略实现，详情参见下面两个链接：

Discuz!NT中的Redis架构设计

Discuz!NT中进行缓存分层(本地缓存+memcached)

这里对LLServer也不例外，同样引入了相应的策略实现，如下：

Discuz.EntLib\LLServer\LLStrategy.cs
Discuz.EntLib\LLServer\LLManager.cs

顾名思义，LLStrategy.cs即是策略实现，LLManager.cs只是一个访问LLServer服务端的一个客户端封装。下面分别看一下源代码，首先是LLStrategy.cs：

/// <summary>
/// 企业级llserver缓存策略类
/// </summary>
public class LLStrategy : DefaultCacheStrategy
{
    /// <summary>
    /// 添加指定ID的对象
    /// </summary>
    /// <param name="objId"></param>
    /// <param name="o"></param>
    public override void AddObject(string objId, object o)
    {
        if (!objId.StartsWith("/Forum/ShowTopic/"))
            base.AddObject(objId, o, LocalCacheTime);

        LLManager.Set(objId, o);
        RecordLog(objId, "set");
    }

    /// <summary>
    /// 加入当前对象到缓存中
    /// </summary>
    /// <param name="objId">对象的键值</param>
    /// <param name="o">缓存的对象</param>
    /// <param name="o">到期时间,单位:秒</param>
    public override void AddObject(string objId, object o, int expire)
    {
        //凡是以"/Forum/ShowTopic/"为前缀不添加到本地缓存中，现类似键值包括: "/Forum/ShowTopic/Tag/{topicid}/" , "/Forum/ShowTopic/TopList/{fid}"
        if (!objId.StartsWith("/Forum/ShowTopic/"))
            base.AddObject(objId, o, expire);

        LLManager.Set(objId, o, expire);
        RecordLog(objId, "set");
    }



    /// <summary>
    /// 移除指定ID的对象
    /// </summary>
    /// <param name="objId"></param>
    public override void RemoveObject(string objId)
    {
        //先移除本地cached，然后再移除memcached中的相应数据
        base.RemoveObject(objId);
        LLManager.Delete(objId);
        Discuz.EntLib.SyncCache.SyncRemoteCache(objId);
    }

    /// <summary>
    /// 获取指定 key 的对象
    /// </summary>
    /// <param name="objId">对象的键值</param>
    public override object RetrieveObject(string objId)
    {
        object obj = base.RetrieveObject(objId);

        if (obj == null)
        {
            obj = LLManager.Get(objId);

            if (obj != null && !objId.StartsWith("/Forum/ShowTopic/"))//对ShowTopic页面缓存数据不放到本地缓存
            {
                if (objId.StartsWith("/Forum/ShowTopicGuestCachePage/"))//对游客缓存页面ShowTopic数据缓存设置有效时间
                    base.TimeOut = GeneralConfigs.GetConfig().Guestcachepagetimeout * 60;
                if (objId.StartsWith("/Forum/ShowForumGuestCachePage/"))//对游客缓存页面ShowTopic数据缓存设置有效时间
                    base.TimeOut = LLServerConfigs.GetConfig().CacheShowForumCacheTime * 60;
                else
                    base.TimeOut = LocalCacheTime;

                base.AddObject(objId, obj, TimeOut);
            }
            RecordLog(objId, "get");

        }
        return obj;
    }

    /// <summary>
    /// 到期时间,单位:秒
    /// </summary>
    public override int TimeOut
    {
        get
        {
            return 3600;
        }
    }

    /// <summary>
    /// 本地缓存到期时间,单位:秒
    /// </summary>
    public int LocalCacheTime
    {
        get
        {
            return LLServerConfigs.GetConfig().LocalCacheTime;
        }
    }

    /// <summary>
    /// 清空的有缓存数据
    /// </summary>
    public override void FlushAll()
    {
        base.FlushAll();
        LLManager.DeleteAll();
    }
}

代码比较简单，大家看一下注释就可以了。下面是LLManager.cs文件的代码：

/// <summary>
/// MemCache管理操作类
/// </summary>
public sealed class LLManager
{
    /// <summary>
    /// redis配置文件信息
    /// </summary>
    private static LLServerConfigInfo llConfigInfo = LLServerConfigs.GetConfig();

    /// <summary>
    /// 静态构造方法，初始化链接池管理对象
    /// </summary>
    static LLManager()
    {
    }

    /// <summary>
    /// 转换 .NET 日期为 UNIX 时间戳
    /// </summary>
    /// <param name="expire">到期时间,单位:秒</param>
    /// <returns></returns>
    private static int GetExpirationUnixTime(int expire)
    {
        if (expire <= 0)
            return 0;

        DateTime expiration = DateTime.Now.AddSeconds(expire);
        if (expiration <= DateTime.Now)
            return 0;

        return Discuz.Common.UnixDateTimeHelper.ConvertToUnixTimestamp(expiration);
    }

    private static readonly BinaryFormatter bf = new BinaryFormatter();
    /// <summary>
    ///  Serialize object to buffer
    /// </summary>
    /// <param name="value">serializable object</param>
    /// <returns></returns>
    public static byte[] Serialize(object value)
    {
        if (value == null)
            return null;
        var memoryStream = new MemoryStream();
        memoryStream.Seek(0, 0);
        bf.Serialize(memoryStream, value);
        return memoryStream.ToArray();
    }

    /// <summary>
    ///     Deserialize buffer to object
    /// </summary>
    /// <param name="someBytes">byte array to deserialize</param>
    /// <returns></returns>
    public static object Deserialize(byte[] someBytes)
    {
        if (someBytes == null)
            return null;
        var memoryStream = new MemoryStream();
        memoryStream.Write(someBytes, 0, someBytes.Length);
        memoryStream.Seek(0, 0);
        return bf.Deserialize(memoryStream);
    }

    public static string ToBase64(byte[] binBuffer)
    {
        int base64ArraySize = (int)Math.Ceiling(binBuffer.Length / 3d) * 4;
        char[] charBuffer = new char[base64ArraySize];
        Convert.ToBase64CharArray(binBuffer, 0, binBuffer.Length, charBuffer, 0);
        return new string(charBuffer);
    }

    /// <summary>
    /// 将Base64编码文本转换成Byte[]
    /// </summary>
    /// <param name="base64">Base64编码文本</param>
    /// <returns></returns>
    public static Byte[] Base64ToBytes(string base64)
    {
        char[] charBuffer = base64.ToCharArray();
        return Convert.FromBase64CharArray(charBuffer, 0, charBuffer.Length);
    }

    /// <summary>
    /// 获取指定 key 的对象
    /// </summary>
    /// <param name="t">对象的键值</param>
    /// <param name="objId">对象的键值</param>
    public static object Get(string objId)
    {
        string result = Utils.GetHttpWebResponse(llConfigInfo.ServerList + "opt=get&charset=utf-8&key=" + objId, "GET", null);

        if (result == null || result.EndsWith("ERROR"))
            return null;
        else
            return Deserialize(Base64ToBytes(result.Substring(0, result.IndexOf("$$END$$"))));
    }

    /// <summary>
    /// 设置对象到缓存中
    /// </summary>
    /// <param name="objId">对象的键值</param>
    /// <param name="data">缓存的对象</param>
    public static bool Set(string objId, object data)
    {
        return Set(objId, data, 0);
    }

    /// <summary>
    /// 设置对象到缓存中
    /// </summary>
    /// <param name="objId">对象的键值</param>
    /// <param name="o">缓存的对象</param>
    /// <param name="exptime">到期时间,单位:秒</param>
    public static bool Set(string objId, object data, int exptime)
    {
        exptime = GetExpirationUnixTime(exptime);
        string result = Utils.UrlEncode(ToBase64(Serialize(data))) + "$$END$$";
        result = Utils.GetHttpWebResponse(
                         string.Format("{0}opt=put&charset=utf-8&key={1}{2}&length={3}",
                                      llConfigInfo.ServerList,
                                      objId,
                                      exptime > 0 ? "&exptime=" + exptime : "",
                                      result.Length),
                           "POST",
                           result);
        return result != null && !result.EndsWith("ERROR");
    }

    /// <summary>
    /// 客户端缓存操作对象
    /// </summary>
    public static bool Delete(string objId)
    {
        string result = Utils.GetHttpWebResponse(llConfigInfo.ServerList + "opt=delete&charset=utf-8&key=" + objId, "GET", null);
        return result != null && !result.EndsWith("ERROR");
    }

    /// <summary>
    /// 获取所有对象,暂时未实现非http协议功能
    /// </summary>
    public static string GetAll()
    {
        string result = Utils.GetHttpWebResponse(llConfigInfo.ServerList + "opt=getlist&charset=utf-8", "GET", null);
        if (result == null || result.EndsWith("ERROR"))
            return null;
        else
            return result;
    }

    /// <summary>
    /// 删除所有缓存对象
    /// </summary>
    public static bool DeleteAll()
    {
        string result = Utils.GetHttpWebResponse(llConfigInfo.ServerList + "opt=deleteall&charset=utf-8", "GET", null);
        if (result == null || result.EndsWith("ERROR"))
            return false;
        else
            return true;
    }
}

    LLManager.cs类主要是以封装了以http协议方式访问llserver的操作（因为llserver可支持http协议和memcached socket协议）。该类有两个地方需要注意：
    1.使用base64对value部分进行编码，以解决object对象二进制序列化后llserver无法存储的问题（llserver这个问题将会在后续版本中解决）
    2.在set/get操作时，对value结尾添加“$$END$$”标识来告之数据在该标识位结束。

了解了这些内容之后，最后再说一个企业版中使用memcached socket协议连接llserver的情况。因为之前企业版中已使用了memcached，这里如果要使用llserver,只须关闭当前llserver.config文件中的

<ApplyLLServer>false</ApplyLLServer>

并开启memcached.config文件中的

选项即可，但同时也要设置该文件的“<ApplyBase64>true</ApplyBase64>”节点，这样就可以用该memcached client来链接使用llserver了。

好了，到这里今天的内容就先告一段落了。

   原文链接:http://www.cnblogs.com/daizhj/archive/2011/08/26/discuznt_llserver_arch.html
   作者: daizhj, 代震军
   微博: http://weibo.com/daizhj
   Tags: discuz!nt, memcached, redis,llserver,key/value db

本文链接

LLServer1.0及C#客户端正式发布并开源

2011-08-23T05:20:00Z

LLServer是本人基于libevent和leveldb这两个开源软件，开发的轻量级数据存储服务器软件，借助libevent高效网络接口实现对leveldb的访问封装。

项目网址：http://code.google.com/p/llserver/
　使用环境：Linux
　作者：代震军
　目前发布版本：1.0
　
　其支持http协议和memcached协议。也就是可以通过浏览器或现有的memcached客户端来进行数据的CURD操作。
下面简单介绍一下如何安装使用LLServer。

LLServer 编译安装：
1.安装libevent2.0

ulimit -SHn 65535
wget http://monkey.org/~provos/libevent-2.0.12-stable.tar.gz
tar zxvf libevent-2.0.12-stable.tar.gz
cd libevent-2.0.12-stable/
./configure --prefix=/usr
make && make install
cd ../

    2.通过svn:客户端下载leveldb到本地leveldb文件夹,链接：http://leveldb.googlecode.com/svn/trunk/
    或暂时用我这个打好包的地址下载：
        wget http://llserver.googlecode.com/files/leveldb.tar.gz
        tar zxvf leveldb.tar.gz
    之后编译安装

cd leveldb/
make -f Makefile
cp libleveldb.a /usr/local/lib/
cp -rf include/* /usr/local/include/
cd ../

3.LLServer下载地址：

wget http://llserver.googlecode.com/files/llserver-1.0.tar.gz
tar zxvf llserver-1.0.tar.gz
cd llserver/
make -f Makefile
make install
cd ../

4、LLServer 使用文档：
　[root@~]# llserver -h
    -l <ip_addr> 监听的IP地址，默认值为 0.0.0.0
    -p <num> 监听的TCP端口（默认值：11211）
    -x <path> 数据库目录，目录不存在会自动创建（例如：/llserver/data）
    -c 数据缓存队列单位，默认为100m
    -t <second> HTTP请求的超时时间
    -s 1:http协议 other:memcached协议
    -d 以守护进程运行
    -h 显示帮助

使用示例：

llserver -l 127.0.0.1 -p 11211 -d -s 1 -x /llserver/db0

　 HTTP GET 协议（以curl命令为例）：

curl "http://127.0.0.1:11211/?opt=set&charset=utf-8&key=username&value=daizhj"
curl "http://127.0.0.1:11211/?opt=set&charset=utf-8&key=username&value=daizhj&exptime=(unix时间戳，设置有效期)"

HTTP POST 协议（以curl命令为例）：

curl -d "daizhj" "http://127.0.0.1:11211/?opt=set&charset=utf-8&key=username"

   打开浏览器：
   如果set成功，返回：LLServer_SET_OK

　如果set失败，返回：LLServer_SET_ERROR

　获取数据：
　HTTP GET 协议（以curl命令为例）：
   curl "http://127.0.0.1:11211/?opt=get&charset=utf-8&key=username"
   打开浏览器：
   如果get成功，返回相应数据信息

　如果get失败，返回：LLServer_GETKEY_ERROR

　
　删除数据：
　HTTP GET 协议（以curl命令为例）：
   curl "http://127.0.0.1:11211/?opt=delete&key=username"
   打开浏览器：
   如果delete成功，返回：LLServer_DELETE_OK

　如果delete失败，返回：LLServer_DELETE_ERROR
　
　删除全部数据：
　HTTP GET 协议（以curl命令为例）：
   curl "http://127.0.0.1:11211/?opt=deleteall&key=username"
   打开浏览器：
    如果delete成功，返回：LLServer_DELETEALL_OK
　如果delete失败，返回：LLServer_DELETEALL_ERROR
　
　
　使用telnet链接示例(基于memcached协议)：

llserver -l 10.0.4.188 -p 11211 -d -s 2 -x /llserver/db1

   set操作：
     client => set username 0 0 6
                daizhj
     llserver=> STORED

   get操作：
     client=>   get username
     llserver=> daizhj

   delete操作：
     client=>   delete username
     llserver=> DELETED

   quit：
     client=>   quit
     llserver=> close client_fd

   version：
     client=> version
     llserver=>1.0




   客户端 C#源码包：

   1.这里将Discuz!NT使用的memcached 客户端（已修改过部分代码），大家可以使用它（支持链接池）来直接访问LLServer,相应的示例在压缩包的MemcachedApp\MemcachedApp\sample\sample_1.aspx中。
     下载地址：http://files.cnblogs.com/daizhj/MemcachedApp_llserver.rar

   2.当然也可以使用c#的httpwebrequest来直接访问，比如（代码源自discuz!nt）：

namespace Discuz.Common
{
    /// <summary>
    /// http POST请求url
    /// </summary>
    /// <param name="url">请求的url链接</param>
    /// <param name="method">方法名称，如"POST", "GET"</param>
    /// <param name="postData">方法名称为"POST"时，所有提交的数据</param>
    /// <returns></returns>
   public static string GetHttpWebResponse(string url, string method, string postData)
   {
       HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(url);
       request.Method = method;
       request.ContentType = "application/x-www-form-urlencoded";
       request.ContentLength = string.IsNullOrEmpty(postData) ? 0 : postData.Length;
       //request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
       request.Timeout = 60000;
       HttpWebResponse response = null;

       try
       {
           if (!string.IsNullOrEmpty(postData))
           {
               StreamWriter swRequestWriter = new StreamWriter(request.GetRequestStream());
               swRequestWriter.Write(postData);

               if (swRequestWriter != null)
                   swRequestWriter.Close();
           }

           response = (HttpWebResponse)request.GetResponse();
           using (StreamReader reader = new StreamReader(response.GetResponseStream(), Encoding.UTF8))
           {
               return reader.ReadToEnd();
           }
       }
       catch
       {
           return null;
       }
       finally
       {
           if (response != null)
               response.Close();
       }
   }

   //这里发送请求并返回数据
   string result = GetHttpWebResponse("http://127.0.0.1:11211/?opt=get&charset=utf-8&key=username", "GET", null);

　当然你可也以用其它语言的memcached客户端来访问LLServer,不过有一点要说明的是，目前llserver只存储序列化的字符串对象，如果你的数据为泛型或数组等类型，请先序列化之后再进行存储。　
　还有就是在c#里可以对数据进行二进制序列化，这里必须将序列化后的对象进行base64位编码之后再存储，否则会报异常，切记。　

　http://blog.nosqlfan.com/html/2819.html LevelDB、TreeDB、SQLite3性能对比测试
　http://blog.nosqlfan.com/html/2882.html LevelDB内部实现

　好了，大家下载体验一下吧，操作数据速度飞快呀。

   原文链接:http://www.cnblogs.com/daizhj/archive/2011/08/23/2150422.html
   作者: daizhj, 代震军
   微博: http://weibo.com/daizhj
   Tags: libevent,leveldb,llserver,key/value db

本文链接

Mongodb源码分析--Replication之OpLog

2011-06-27T03:50:00Z

在之前的文章中，介绍了关于master-slave模式下的主从端代码的执行流程，因为当时篇幅所限，未对oplog的数据结构以及mongodb的local数据库作过多阐述，而这可能会让不知道其内容的朋友看代码时云里雾里找不到头绪，今天我专门用一篇文章来大致解释一下（这些内容可能会在后面章节中有所涉及）。

      首先了解一个local数据库:
      在mongod中，出于特殊目的（复制机制），保留性使用了local数据库。当使用认证机制时，对local数据库等同于认证admin数据库。

      当使用复制集(Replica sets)模式时，其会使用下面的local数据库：

local.system.replset 用于复制集配置对象存储 (通过shell下的rs.conf()或直接查询)
local.oplog.rs 一个capped collection集合.可在命令行下使用--oplogSize 选项设置该集合大小尺寸.
local.replset.minvalid 通常在复制集内使用，用于跟踪同步状态(sync status)

主从复制模式(Master/Slave):

    * Master
          o local.oplog.$main 存储"oplog"信息
          o local.slaves  存储在master结点上相应slave结点的同步情况（比如syncTo时间戳等）
    * Slave
          o local.sources 从结点所要链接的master结点信息（可通过--source配置参数指定）
    * Other
          o local.me 未知待查:)
          o local.pair.* (replica pairs选项，目前已不推荐使用)

    除了了解local之外，还有oplog的数据结构（存储在local.oplog.$main）要解释一下：

   { ts : ..., op: ..., ns: ..., o: ... o2: ... }

   上面就是一条oplog信息，复制机制就是通过这些信息来进行节点间的数据同步并维护数据一致性的，其中：

    ts：8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示。
        这个值很重要，在选举(如master宕机时)新primary时，会选择ts最大的那个secondary作为新primary。
    op：1字节的操作类型，例如i表示insert，d表示delete。
    ns：操作所在的namespace。
    o：操作所对应的document,即当前操作的内容（比如更新操作时要更新的的字段和值）
    o2: 在执行更新操作时的where条件，仅限于update时才有该属性

其中op，可以是如下几种情形之一：

     "i"： insert
     "u"： update
     "d"： delete
     "c"： db cmd
     "db"：声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')
     "n":  no op,即空操作，其会定期执行以确保时效性

了解了这些内容之后，大家通过下面方式来验证一下上面的这些内容：
1.本地构造复制集

D:\mongodb\bin>mongod --replSet myoplogs --dbpath d:\mongodb\db

2.使用mongo连接到上面结点并初始化

    D:\mongodb\bin>mongo
      MongoDB shell version: ...
      connecting to: test
      > rs.initiate()

3.查看oplog复制集信息

> use local
switched to db local
> db.oplog.rs.find()

{"ts" : { "t" : 1306207268000, "i" : 1 }, "h" : NumberLong(0), "op" : "n", "ns" : "", "o" : { "msg" : "initiating set" } }

4.开始添加记录

  > use test
     switched to db test
   > db.foo.insert({x:1})
   > db.foo.update({x:1}, {$set : {y:1}})
   > db.foo.update({x:2}, {$set : {y:1}}, true)
   > db.foo.remove({x:1})

5.查看上面操作生成的oplog信息：

   > use local
     switched to db local
   > db.oplog.rs.find()

    { "ts" : { "t" : 1306207268000, "i" : 1 }, "h" : NumberLong(0), "op" : "n", "ns" : "", "o" : { "msg" : "initiating set" } }
    { "ts" : { "t" : 1306207310000, "i" : 1 }, "h" : NumberLong("3138280161636515857"), "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("4ddb244d2d0d00000000551a"), "x" : 1 } }
    { "ts" : { "t" : 1306207314000, "i" : 1 }, "h" : NumberLong("772196482295043060"), "op" : "u", "ns" : "test.foo", "o2" : { "_id" : ObjectId("4ddb244d2d0d00000000551a") }, "o" : { "$set" : { "y" : 1 } } }
    { "ts" : { "t" : 1306207317000, "i" : 1 }, "h" : NumberLong("7272647888810218413"), "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("4ddb2455be10000000002f6a"), "x" : 2, "y" : 1 } }
    { "ts" : { "t" : 1306207325000, "i" : 1 }, "h" : NumberLong("3083832920223263240"), "op" : "d", "ns" : "test.foo", "b" : true, "o" : { "_id" : ObjectId("4ddb244d2d0d00000000551a") } }

   注：其它常用命令：db.oplog.$main.help() db.printReplicationInfo();

   知道上面这些内容之后，我们来大致看一下mongod在源码层面上是如何存储oplog的，先请看下面文件：

   oplog.cpp：顾名思义，它的作用就是存储和读取oplog，其主要包括方法：

   createOplog()：初始化本地local.oplog.$main 集合信息，包括大小尺寸等
   _logOpOld():   用于在master/slave模式下向local.oplog.$main 添加oplog信息
   _logOpObjRS():    用于在replset模式下向local.oplog.rs模式下添加oplog 信息
   append_O_Obj():向已存在的obj对象后追加新的对象元素信息（主要用于更新类型的oplog）
   pretouchN()及pretouchOperation():某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。这里使用下面的优化方式来避免锁定：每次更新前，先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在"主/从"部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。

下面就借助源码来进一步深入了解，首先回顾一下之前这篇文章中的所描述的这段代码：

   //repl.cpp
   void startReplication() {
        /* if we are going to be a replica set, we aren't doing other forms of replication. */
        if( !cmdLine._replSet.empty() ) {
            ......
            //绑定函数，oplog.cpp ->_logOpRS(), 用于处理replset类型的oplog操作
            newRepl();
            return;
        }
        //绑定函数，oplog.cpp ->_logOpOld(), 用于处理master-slave类型的oplog操作
        oldRepl();

     上面的newRepl()及oldRepl()主要是实现函数绑定，它会将oplog.cpp文件中的_logOpRS和_logOpOld方法加以绑定（本人猜测可能因为1.6版之后引入了replset，造成方法名称的重新命名和分配，导致这里用这种方式对老的方法进行“过渡”）。

   接着上面方面会调用oplog.cpp文件的createOplog（）来构造master的“local.oplog.$main”集合,如下：

    //如果是master，则构造并启动线程方法replMasterThread
     if ( replSettings.master || replPair ) {
            if ( replSettings.master )
                log(1) << "master=true" << endl;
            replSettings.master = true;
            //构造oplog集合"local.oplog.$main"
            createOplog();
            boost::thread t(replMasterThread);
        }

在上面初始化及函数指针绑定任务完成了，就可以在数据同步时，根据oplog集合信息来进行同步了，如下：

//repl.cpp
   void ReplSource::sync_pullOpLog_applyOperation(BSONObj& op, OpTime *localLogTail, bool alreadyLocked) {
     .....
     if( cmdLine.pretouch && !alreadyLocked /*在非写锁下,因为写锁下进行pretouch操作没意义*/) {
            if( cmdLine.pretouch > 1 ) {
                /* note: this is bad - should be put in ReplSource.  but this is first test... */
                static int countdown;
                assert( countdown >= 0 );
                if( countdown > 0 ) {
                    countdown--; // was pretouched on a prev pass
                }
                else {
                    const int m = 4;
                    if( tp.get() == 0 ) {
                        int nthr = min(8, cmdLine.pretouch);
                        nthr = max(nthr, 1);
                        tp.reset( new ThreadPool(nthr) );
                    }
                    vector<BSONObj> v;
                    oplogReader.peek(v, cmdLine.pretouch);
                    unsigned a = 0;
                    while( 1 ) {
                        if( a >= v.size() ) break;
                        unsigned b = a + m - 1; // v[a..b]
                        if( b >= v.size() ) b = v.size() - 1;
                        tp->schedule(pretouchN, v, a, b);
                        DEV cout << "pretouch task: " << a << ".." << b << endl;
                        a += m;
                    }
                    //执行oplog.cpp中的预取操作
                    pretouchOperation(op);
                    tp->join();
                    countdown = v.size();
                }
            }
            else {
                //执行oplog.cpp中的预取操作
                pretouchOperation(op);
            }
        }
        ......
        //使用获取到的oplog操作信息进行同步操作，有关该方法本人已在这个链接中有关介绍
        //Mongodb源码分析--Replication之主从模式--Slave
        applyOperation( op );
        ......
    }

上面方法中出现了预取操作，该技术主要是出现运行效率的考虑，下面是pretouchOperation方法的具体实现(pretouch方法实现与其大同小异，感兴趣的朋友可自行阅读)：

//oplog.cpp中的相应方法
    //某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。
    //这里使用下面的优化方式来避免锁定：
    //    每次更新前，先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。
    //在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。
    void pretouchOperation(const BSONObj& op) {
        // no point pretouching if write locked.
        //not sure if this will ever fire, but just in case.
        if( dbMutex.isWriteLocked() )//写锁下则不执行pretouch操作
            return;

        const char *which = "o";//数据的对象
        const char *opType = op.getStringField("op");
        if ( *opType == 'i' )
            ;
        else if( *opType == 'u' )//如是更新操作时，则执行touch
            which = "o2";//更新的条件pattern
        else
            return;
        /* todo : other operations */

        try {
            BSONObj o = op.getObjectField(which);
            BSONElement _id;
            //获取_id信息,用于下面find查找
            if( o.getObjectID(_id) ) {
                const char *ns = op.getStringField("ns");
                BSONObjBuilder b;
                b.append(_id);
                BSONObj result;
                readlock lk(ns);
                Client::Context ctx( ns );
                //获取要更新的obj
                if( Helpers::findById(cc(), ns, b.done(), result) )
                    _dummy_z += result.objsize(); // touch
            }
        }
        catch( DBException& ) {
            log() << "ignoring assertion in pretouchOperation()" << endl;
        }
    }

说到这里只是获取oplog的操作，那mongod进行cud操作时，log是如何记录到日志集合中的呢？还记得上面提到的函数绑定吗？我们来看一下oplog.cpp中的下面方法：

  /*@ @param opstr:
          c userCreateNS
          i insert
          n no-op / keepalive
          d delete / remove
          u update
    */
    void logOp(const char *opstr, const char *ns, const BSONObj& obj, BSONObj *patt, bool *b) {
        if ( replSettings.master ) {
            _logOp(opstr, ns, 0, obj, patt, b);//这里将会执行之前函数绑定的方法,比如：_logOpOld
        }
        //用于在shard模式下oplog操作
        logOpForSharding( opstr , ns , obj , patt );
    }

上面的logOp方法几乎出现在了所有cud操作场景中，比如在update操作时：

   //update.cpp
   static UpdateResult _updateById(bool isOperatorUpdate, int idIdxNo, ModSet *mods, int profile, NamespaceDetails *d,
                                    NamespaceDetailsTransient *nsdt,
                                    bool god, const char *ns,
                                    const BSONObj& updateobj, BSONObj patternOrig, bool logop, OpDebug& debug) {
              ......
              if ( logop ) {
                 ......
                if( mss->needOpLogRewrite() ) {
                    DEBUGUPDATE( "\t rewrite update: " << mss->getOpLogRewrite() );
                    logOp("u", ns, mss->getOpLogRewrite() , &pattern );//记录日志
                }
                else {
                    logOp("u", ns, updateobj, &pattern );//记录日志
                }
             }
             .....
   }

这里以_logOpOld()方法为例，来看一下mongod是如何向local.oplog.$main集合中添加oplog日志的：

/* we write to local.oplog.$main:
         { ts : ..., op: ..., ns: ..., o: ... o2: ...  }
       ts: an OpTime timestamp
       op:
        "i" insert
        "u" update
        "d" delete
        "c" db cmd
        "db" declares presence of a database (ns is set to the db name + '.')
        "n" no op

       logNS - where to log it.  0/null means "local.oplog.$main".

       bb:
         if not null, specifies a boolean to pass along to the other side as b: param.
         used for "justOne" or "upsert" flags on 'd', 'u'

       note this is used for single collection logging even when --replSet is enabled.
    */
    static void _logOpOld(const char *opstr, const char *ns, const char *logNS, const BSONObj& obj, BSONObj *o2, bool *bb ) {
        DEV assertInWriteLock();
        static BufBuilder bufbuilder(8*1024);
        //如是master上的local.slaves，则更新该数据库缓存信息
        if ( strncmp(ns, "local.", 6) == 0 ) {
            if ( strncmp(ns, "local.slaves", 12) == 0 ) {
                resetSlaveCache();
            }
            return;
        }
        //获取当前系统时间作为操作时间
        const OpTime ts = OpTime::now();
        Client::Context context;

        /* we jump through a bunch of hoops here to avoid copying the obj buffer twice --
           instead we do a single copy to the destination position in the memory mapped file.
        */
        //生成bson格式的oplog的对象
        bufbuilder.reset();
        BSONObjBuilder b(bufbuilder);
        b.appendTimestamp("ts", ts.asDate());
        b.append("op", opstr);
        b.append("ns", ns);
        if ( bb )
            b.appendBool("b", *bb);
        if ( o2 )//如果不为空，表示执行操作的条件（where）
            b.append("o2", *o2);
        BSONObj partial = b.done(); // partial is everything except the o:... part.

        int po_sz = partial.objsize();
        int len = po_sz + obj.objsize() + 1 + 2 /*o:*/;

        Record *r;
        //为0/null,表示"local.oplog.$main"
        if( logNS == 0 ) {
            logNS = "local.oplog.$main";
            if ( localOplogMainDetails == 0 ) {
                Client::Context ctx( logNS , dbpath, 0, false);
                localDB = ctx.db();
                assert( localDB );
                localOplogMainDetails = nsdetails(logNS);
                assert( localOplogMainDetails );
            }
            Client::Context ctx( logNS , localDB, false );
            //在指定Namespace下的Extent中分配一个record空间，用于下面添加log信息
            r = theDataFileMgr.fast_oplog_insert(localOplogMainDetails, logNS, len);
        }
        else {
            //在指定的logNS中分配一个record空间
            Client::Context ctx( logNS, dbpath, 0, false );
            assert( nsdetails( logNS ) );
            // 如第一次分配first we allocate the space, then we fill it below.
            r = theDataFileMgr.fast_oplog_insert( nsdetails( logNS ), logNS, len);
        }
        //将操作条件(where)追加到已存在对象
        append_O_Obj(r->data, partial, obj);
        //设置最近操作时间
        context.getClient()->setLastOp( ts.asDate() );

        if ( logLevel >= 6 ) {
            BSONObj temp(r);
            log( 6 ) << "logging op:" << temp << endl;
        }
    }

    /** given a BSON object, create a new one at dst which is the existing (partial) object
        with a new object element appended at the end with fieldname "o".

        @param partial already build object with everything except the o member.  e.g. something like:
               { ts:..., ns:..., o2:... }
        @param o a bson object to be added with fieldname "o"
        @dst   where to put the newly built combined object.  e.g. ends up as something like:
               { ts:..., ns:..., o2:..., o:... }
    */
    void append_O_Obj(char *dst, const BSONObj& partial, const BSONObj& o) {
        const int size1 = partial.objsize() - 1;  // less the EOO char
        const int oOfs = size1+3;                 // 3 = byte BSONOBJTYPE + byte 'o' + byte \0

        void *p = getDur().writingPtr(dst, oOfs+o.objsize()+1);

        memcpy(p, partial.objdata(), size1);

        // adjust overall bson object size for the o: field
        *(static_cast<unsigned*>(p)) += o.objsize() + 1/*fieldtype byte*/ + 2/*"o" fieldname*/;

        char *b = static_cast<char *>(p);
        b += size1;
        *b++ = (char) Object;
        *b++ = 'o'; // { o : ... }
        *b++ = 0;   // null terminate "o" fieldname
        memcpy(b, o.objdata(), o.objsize());
        b += o.objsize();
        *b = EOO;
    }

   好了，关于oplog的主要内容介绍的差不多了，感兴趣的朋友可以下载相关源码做进一步的分析。

   参考链接：
   http://www.snailinaturtleneck.com/blog/2010/10/14/getting-to-know-your-oplog/
   http://www.snailinaturtleneck.com/blog/2010/08/02/replica-sets-part-2-what-are-replica-sets/


   原文链接:http://www.cnblogs.com/daizhj/archive/2011/06/27/mongodb_sourcecode_oplog.html
    作者: daizhj, 代震军
    微博: http://t.sina.com.cn/daizhj
    Tags: mongodb,c++,Replica,master-slave,oplog,local database

本文链接

Mongodb源码分析--Replication之主从模式--Slave

2011-06-20T00:32:00Z

    在上文中介绍了主从(master-slave)模式下的一些基本概念及master的执行流程。今天接着介绍一下从(slave)结点是如何发起请求，并通过请求获取的oplog信息来构造本地数据的。

   不过开始今天的正文前，需要介绍一下mongodb在slave结点上进行数据同步时的一个大致流程：

    1.当一个从结点启动时，它会对主结点进行一次彻底同步。从结点将复制主结点中的每一个文档（操作量大且耗时）。当初始化的同步完成后，从结点将查询主结点的oplog并且执行这些操作来保持数据的更新。

    2.如从结点上的操作落后主结点太多，从结点处于out-of-sync状态。该状态表示从结点不能通过执行同步操作使本地数据赶上主结点数据，因为主结点中的每一个操作都太新了。造成这种情况的原因包括结点宕机或者忙于处理读请求（尽管mongodb支持读操作的负载均衡）。如果同步的时间(戳)超出了oplog(滚动)的时间(戳)，它将重新开始一次彻底的同步（通过执行resync操作）。

    3.当一个从结点处于out-of-sync状态时，复制将被挂起，从结点需要从主结点进行重新同步。resync流程可以手动执行，即在从结点的admin数据库上运行命令{“resync”：1}，或者自动执行：在启动从结点时使用 --autoresync选项。因为resync是非常操作量大且耗时，最好通过设置一个足够大的oplogSize来避免resync（默认的oplog大小是空闲磁盘大小的5%）。

    为了验证上面的流程，下面我们就来看一下slave的执行流程。这里为了便于调试，对环境配置如下：

   1.master db ip-> 10.0.4.210
      启动命令行：d:\mongod>bin>mongod --dbpath=d:\mongodb\db --master --oplogSize 64

   2.在vs中做如下设置（mongod项目属性窗口）：
      --slave --source 10.0.4.210:27017 --only test --slavedelay 100

   因为mongod的主入口函数在db.cpp中，我们可以通过下面方法的调用流程找到slave的蛛丝马迹：

db.cpp-->
     main(int argc, char* argv[]) //加载启动参数如--slave，--slavedelay并绑定到replSettings对象
         void initAndListen(int listenPort, const char *appserverLoc = NULL)
            void _initAndListen(int listenPort, const char *appserverLoc = NULL)
                 listen(int port)

当执行到listen()方法后(如下)：

void listen(int port) {
        //testTheDb();
        log() << "waiting for connections on port " << port << endl;
        OurListener l(cmdLine.bind_ip, port);
        l.setAsTimeTracker();
        //启动复制
        startReplication();
        if ( !noHttpInterface )
            boost::thread web( boost::bind(&webServerThread, new RestAdminAccess() /* takes ownership */));

        .....
    }

mongodb会紧跟着执行repl.cpp文件中的startReplication()方法，如下：

//repl.cpp
   void startReplication() {
        /* if we are going to be a replica set, we aren't doing other forms of replication. */
        if( !cmdLine._replSet.empty() ) {
            //如果使用分布集群，则不允许带slave或master选项
            if( replSettings.slave || replSettings.master || replPair ) {
                log() << "***" << endl;
                log() << "ERROR: can't use --slave or --master replication options with --replSet" << endl;
                log() << "***" << endl;
            }
            //绑定函数，oplog.cpp ->_logOpRS(), 用于处理replset类型的oplog操作
            newRepl();
            return;
        }
        //绑定函数，oplog.cpp ->_logOpOld(), 用于处理master-slave类型的oplog操作
        oldRepl();

        /* this was just to see if anything locks for longer than it should -- we need to be careful
           not to be locked when trying to connect() or query() the other side.
           */
        //boost::thread tempt(tempThread);
        //当设置参数不正确时（非slave，master且不是replPair）
        if( !replSettings.slave && !replSettings.master && !replPair )
            return;

        {
            dblock lk;
            cc().getAuthenticationInfo()->authorize("admin");
            pairSync->init();
        }
        //如果是slave，则开启相关访问（master server）线程
        if ( replSettings.slave || replPair ) {
            if ( replSettings.slave ) {
                assert( replSettings.slave == SimpleSlave );
                log(1) << "slave=true" << endl;
            }
            else
                replSettings.slave = ReplPairSlave;
            //构造并启动线程方法replSlaveThread
            boost::thread repl_thread(replSlaveThread);
        }
        //如果是master，则构造并启动线程方法replMasterThread
        if ( replSettings.master || replPair ) {
            if ( replSettings.master )
                log(1) << "master=true" << endl;
            replSettings.master = true;
            createOplog();//构造oplog集合“local.oplog.$main”
            boost::thread t(replMasterThread);
        }
        // don't allow writes until we've set up from log
        while( replSettings.fastsync )
            sleepmillis( 50 );
    }

上面方法在完成必要的参数分析检查之后，就会根据slave的配置信息来构造启动线程方法replSlaveThread，如下：

    //repl.cpp
    void replSlaveThread() {
        sleepsecs(1);
        Client::initThread("replslave");
        cc().iAmSyncThread();

        {
            dblock lk;
            //获取认证信息（mongodb支持使用安全认证不管哪种replicate方式，
            //只要在master/slave中创建一个能为各个database认识的用户名/密码即可)
            cc().getAuthenticationInfo()->authorize("admin");

            ......
        }

        while ( 1 ) {
            try {
                //repl主函数
                replMain();
                if ( debug_stop_repl )
                    break;
                sleepsecs(5);//休眠5秒
            }
            catch ( AssertionException& ) {
                ReplInfo r("Assertion in replSlaveThread(): sleeping 5 minutes before retry");
                problem() << "Assertion in replSlaveThread(): sleeping 5 minutes before retry" << endl;
                sleepsecs(300);
            }
        }
    }

上面方法中有mongodb进行认证的逻辑，之后就会用一个while(1)来循环执行（注：每5秒执行一次）replMain()方法，如下：

//repl.cpp
    void replMain() {
        ReplSource::SourceVector sources;
        while ( 1 ) {
            int s = 0;
            {
                dblock lk;
                //复制失败
                if ( replAllDead ) {//该标识符会在同步出现异常如(out of sync)时为true
                    //autoresync:自动地重新执行完整的同步，如果这个从结点脱离了与主结点的同步。
                    if ( !replSettings.autoresync || !ReplSource::throttledForceResyncDead( "auto" ) )
                        break;
                }
                // i.e., there is only one sync thread running.
                // we will want to change/fix this.
                assert( syncing == 0 );
                syncing++;
            }
            try {
                int nApplied = 0;
                //repl主函数
                s = _replMain(sources, nApplied);
                if( s == 1 ) {
                    if( nApplied == 0 ) s = 2;
                    else if( nApplied > 100 ) {
                        // sleep very little - just enought that we aren't truly hammering master
                        sleepmillis(75);
                        s = 0;
                    }
                }
            }
            catch (...) {
                out() << "caught exception in _replMain" << endl;
                s = 4;
            }
            ......
     }

上面代码又是一个while(1)循环，它会判断当前slave是否处于“out of sync”状态，如果是，但未开启autoresync时，则复制将被挂起。否则会执行_replMain方法来进行同步，如下：

    //repl.cpp
     int _replMain(ReplSource::SourceVector& sources, int& nApplied) {
        {
            ReplInfo r("replMain load sources");
            dblock lk;
            ReplSource::loadAll(sources);//绑定相应的master sources,以便后面遍历同步
            /*fastsync: 从主结点的快照中启动一个从结点。与完整的同步相比，
            这个选项允许一个从结点更快地启动，如果它的数据目录已经使用主结点的快照进行初始化。*/
            replSettings.fastsync = false; // 初始重置时需要该参数
        }
        .....

        int sleepAdvice = 1;
        for ( ReplSource::SourceVector::iterator i = sources.begin(); i != sources.end(); i++ ) {
            ReplSource *s = i->get();
            int res = -1;
            try {
                res = s->sync(nApplied);
                //是否有其它要同步的数据库
                bool moreToSync = s->haveMoreDbsToSync();
                if( res < 0 ) {
                    sleepAdvice = 3;
                }
                else if( moreToSync ) {
                    sleepAdvice = 0;
                }
                else if ( s->sleepAdvice() ) {
                    sleepAdvice = s->sleepAdvice();
                }
                else
                    sleepAdvice = res;
                if ( res >= 0 && !moreToSync /*&& !s->syncedTo.isNull()*/ ) {
                    pairSync->setInitialSyncCompletedLocking();
                }
            }
            ......
        }
        return sleepAdvice;
    }

上面的_replMain()方法首先会从“local.sources”数据集中获取主（master）节点的信息。这里解释一下，mongod从结点在启动时会将启动参数(--source)中的信息保存到"local.sources"数据集中,并通过此函数（loadAll()）中加载到一个集合对象中。这里我们看一下其加载代码，如下：

/* slave: pull some data from the master's oplog
       note: not yet in db mutex at this point.
       @return -1 error
               0 ok, don't sleep
               1 ok, sleep
    */
    //repl.cpp
    void ReplSource::loadAll(SourceVector &v) {
        Client::Context ctx("local.sources");
        SourceVector old = v;
        v.clear();

        ......
        //遍历local.sources，并将其中的replsource绑定到SourceVector中
        shared_ptr<Cursor> c = findTableScan("local.sources", BSONObj());
        while ( c->ok() ) {
            ReplSource tmp(c->current());
            if ( replPair && tmp.hostName == replPair->remote && tmp.sourceName() == "main" ) {
                gotPairWith = true;
                tmp.paired = true;
                if ( replacePeer ) {
                    // peer was replaced -- start back at the beginning.
                    tmp.syncedTo = OpTime();
                    tmp.replacing = true;
                }
            }
            if ( ( !replPair && tmp.syncedTo.isNull() ) ||
                     ( replPair && replSettings.fastsync ) ) {
                DBDirectClient c;
                //主服务器进程创建的local.oplog.$main数据集，即"transaction log"，以记录从服务器需要的操作队列信息。
                //这里用于获取同步时的时间戳"syncedTo"
                if ( c.exists( "local.oplog.$main" ) ) {
                    BSONObj op = c.findOne( "local.oplog.$main", QUERY( "op" << NE << "n" ).sort( BSON( "$natural" << -1 ) ) );
                    if ( !op.isEmpty() ) {
                        tmp.syncedTo = op[ "ts" ].date();
                        tmp._lastSavedLocalTs = op[ "ts" ].date();
                    }
                }
            }
            //将source数据绑定到v中以引用方式（&v）返回给上一级函数调用
            addSourceToList(v, tmp, old);
            c->advance();
        }
        ......
    }

完成了source的加载之后，就可以开始对source进行同步了，即如下代码：

int ReplSource::sync(int& nApplied) {
        _sleepAdviceTime = 0;
        ReplInfo r("sync");
        if ( !cmdLine.quiet ) {
            Nullstream& l = log();
            l << "repl: from ";
            if( sourceName() != "main" ) {
                l << "source:" << sourceName() << ' ';
            }
            l << "host:" << hostName << endl;
        }
        nClonedThisPass = 0;

        // 对于localhost这类本机地址，则不能同步
        //FIXME Handle cases where this db isn't on default port, or default port is spec'd in hostName.
        if ( (string("localhost") == hostName || string("127.0.0.1") == hostName) && cmdLine.port == CmdLine::DefaultDBPort ) {
            log() << "repl:   can't sync from self (localhost). sources configuration may be wrong." << endl;
            sleepsecs(5);
            return -1;
        }
        //oplogReader链接时出现异常
        if ( !oplogReader.connect(hostName) ) {
            log(4) << "repl:  can't connect to sync source" << endl;
            if ( replPair && paired ) {
                assert( startsWith(hostName.c_str(), replPair->remoteHost.c_str()) );
                replPair->arbitrate();//paired模式下同级结点进行仲裁
            }
            return -1;
        }

        if ( paired ) {
            int remote = replPair->negotiate(oplogReader.conn(), "direct");
            int nMasters = ( remote == ReplPair::State_Master ) + ( replPair->state == ReplPair::State_Master );
            //主库不为1时，则异常
            if ( getInitialSyncCompleted() && nMasters != 1 ) {
                log() << ( nMasters == 0 ? "no master" : "two masters" ) << ", deferring oplog pull" << endl;
                return 1;
            }
        }
        ......

        return sync_pullOpLog(nApplied);//根据oplog日志进行同步
    }

上面方法先进行一些异常判断，比如source为localhost地址，以及无法链接（oplogReader.connect）等情况。之后，调用sync_pullOpLog方法，从master上获取oplog来同步数据信息，如下：

//repl.cpp 获取主库的oplog数据
    int ReplSource::sync_pullOpLog(int& nApplied) {
        int okResultCode = 1;
        //获取主库中oplog的名空间信息
        string ns = string("local.oplog.$") + sourceName();
        log(2) << "repl: sync_pullOpLog " << ns << " syncedTo:" << syncedTo.toStringLong() << '\n';

        bool tailing = true;
        oplogReader.tailCheck();

        if ( replPair && replPair->state == ReplPair::State_Master ) {
            dblock lk;
            idTracker.reset();
        }
        OpTime localLogTail = _lastSavedLocalTs;
        //是否初始化
        bool initial = syncedTo.isNull();
        //无游标支持或要初始化时
        if ( !oplogReader.haveCursor() || initial ) {
            if ( initial ) {
                //显示数据库信息之前，获取最新(last)的 oplog日志时间戳.
                syncToTailOfRemoteLog();
                BSONObj info;
                bool ok = oplogReader.conn()->runCommand( "admin", BSON( "listDatabases" << 1 ), info );
                massert( 10389 ,  "Unable to get database list", ok );
                BSONObjIterator i( info.getField( "databases" ).embeddedObject() );
                while( i.moreWithEOO() ) {
                    BSONElement e = i.next();
                    if ( e.eoo() )
                        break;
                    string name = e.embeddedObject().getField( "name" ).valuestr();
                    if ( !e.embeddedObject().getBoolField( "empty" ) ) {
                        if ( name != "local" ) {
                            if ( only.empty() || only == name ) {
                                log( 2 ) << "adding to 'addDbNextPass': " << name << endl;
                                addDbNextPass.insert( name );
                            }
                        }
                    }
                }
                dblock lk;
                save();
            }
            //本次同步的日志时间戳(gte：大于或等于)
            BSONObjBuilder q;
            q.appendDate("$gte", syncedTo.asDate());
            BSONObjBuilder query;
            query.append("ts", q.done());
            if ( !only.empty() ) {
                // note we may here skip a LOT of data table scanning, a lot of work for the master.
                query.appendRegex("ns", string("^") + only); // maybe append "\\." here?
            }
            BSONObj queryObj = query.done();
            // e.g. queryObj = { ts: { $gte: syncedTo } }
            //tailingQuery查询，并绑定其相应游标信息
            oplogReader.tailingQuery(ns.c_str(), queryObj);
            tailing = false;
        }
        else {
            log(2) << "repl: tailing=true\n";
        }
        //如果依旧无游标信息，可能链接被关闭，则尝试重置链接
        if( !oplogReader.haveCursor() ) {
            problem() << "repl: dbclient::query returns null (conn closed?)" << endl;
            oplogReader.resetConnection();
            return -1;
        }

        // show any deferred（延期,搁置）database creates from a previous pass
        {
            set<string>::iterator i = addDbNextPass.begin();
            if ( i != addDbNextPass.end() ) {
                BSONObjBuilder b;
                b.append("ns", *i + '.');
                b.append("op", "db");
                BSONObj op = b.done();
                //找到相应的oplog之后并使用这些oplog操作同步,方法很复杂，这里暂且略过
                sync_pullOpLog_applyOperation(op, 0, false);
            }
        }

        if ( !oplogReader.more() ) {//如没有其它oplog操作，则返回
            if ( tailing ) {//已到cap collection结尾
                log(2) << "repl: tailing & no new activity\n";
                if( oplogReader.awaitCapable() )
                    okResultCode = 0; // don't sleep

            }
            else {
                log() << "repl:   " << ns << " oplog is empty\n";
            }
            {
                dblock lk;
                //最近一次保存到本地操作发生时间
                OpTime nextLastSaved = nextLastSavedLocalTs();
                {
                    dbtemprelease t;
                    if ( !oplogReader.more() ) {
                        //设置_lastSavedLocalTs
                        setLastSavedLocalTs( nextLastSaved );
                    }
                }
                save();
            }
            return okResultCode;
        }
        //下一次操作时间,用于绑定到syncedTo上。
        //syncedTo为时间戳，保存从结点的更新时间，每次从结点需要查询新的oplog时，
        //它使用“syncedTo”获得它需要执行的新的操作，或者发现它已经out-of-sync。
        OpTime nextOpTime;
        {
            BSONObj op = oplogReader.next();
            BSONElement ts = op.getField("ts");
            if ( ts.type() != Date && ts.type() != Timestamp ) {
                string err = op.getStringField("$err");
                //如获取master oplog时出现error
                if ( !err.empty() ) {
                    // 13051 is "tailable cursor requested on non capped collection"
                    if (op.getIntField("code") == 13051) {
                        problem() << "trying to slave off of a non-master" << '\n';
                        massert( 13344 ,  "trying to slave off of a non-master", false );
                    }
                    else {
                        problem() << "repl: $err reading remote oplog: " + err << '\n';
                        massert( 10390 ,  "got $err reading remote oplog", false );
                    }
                }
                else {
                    problem() << "repl: bad object read from remote oplog: " << op.toString() << '\n';
                    massert( 10391 , "repl: bad object read from remote oplog", false);
                }
            }

            if ( replPair && replPair->state == ReplPair::State_Master ) {

                OpTime next( ts.date() );
                if ( !tailing && !initial && next != syncedTo ) {
                    //强制slave 重新同步
                    log() << "remote slave log filled, forcing slave resync" << endl;
                    resetSlave();
                    return 1;
                }

                dblock lk;
                updateSetsWithLocalOps( localLogTail, true );
            }

            nextOpTime = OpTime( ts.date() );
            log(2) << "repl: first op time received: " << nextOpTime.toString() << '\n';
            if ( initial ) {
                log(1) << "repl:   initial run\n";
            }
            if( tailing ) {
                //当出现旧数据被新oplog覆盖的情况时
                if( !( syncedTo < nextOpTime ) ) {
                    log() << "repl ASSERTION failed : syncedTo < nextOpTime" << endl;
                    log() << "repl syncTo:     " << syncedTo.toStringLong() << endl;
                    log() << "repl nextOpTime: " << nextOpTime.toStringLong() << endl;
                    assert(false);
                }
                oplogReader.putBack( op ); // op will be processed in the loop below
                nextOpTime = OpTime(); // will reread the op below
            }
         //如本次同步时间与下一次操作时间不相同，意味着从结点上的操作落后主结点太多，从结点处于out-of-sync状态。
         //一个out-of-sync的从结点不能通过执行操作赶上主结点，因为主结点中的每一个操作都太新了。这可能是因为从
         //结点挂了或者忙于处理读请求。如果同步的时间超出了oplog滚动的时间，它将重新开始一次彻底的同步。
            else if ( nextOpTime != syncedTo ) { // didn't get what we queried for - error
                Nullstream& l = log();
                l << "repl:   nextOpTime " << nextOpTime.toStringLong() << ' ';
                if ( nextOpTime < syncedTo )
                    l << "<??";
                else
                    l << ">";

                l << " syncedTo " << syncedTo.toStringLong() << '\n';
                log() << "repl:   time diff: " << (nextOpTime.getSecs() - syncedTo.getSecs()) << "sec\n";
                log() << "repl:   tailing: " << tailing << '\n';
                log() << "repl:   data too stale, halting replication" << endl;
                replInfo = replAllDead = "data too stale halted replication";
                assert( syncedTo < nextOpTime );
                throw SyncException();
            }
            else {
                /* t == syncedTo, so the first op was applied previously or it is the first op of initial query and need not be applied. */
            }
        }

      //将获取到的oplog操作信息应用到“从结点（slave）”上
        //apply operations
        {
            int n = 0;
            time_t saveLast = time(0);
            while ( 1 ) {

                bool moreInitialSyncsPending = !addDbNextPass.empty() && n; // we need "&& n" to assure we actually process at least one op to get a sync point recorded in the first place.

                if ( moreInitialSyncsPending || !oplogReader.more() ) {
                    dblock lk;
                    OpTime nextLastSaved = nextLastSavedLocalTs();
                    {
                        dbtemprelease t;
                        if ( !moreInitialSyncsPending && oplogReader.more() ) {
                            if ( getInitialSyncCompleted() ) { // if initial sync hasn't completed, break out of loop so we can set to completed or clone more dbs
                                continue;
                            }
                        }
                        else {
                            setLastSavedLocalTs( nextLastSaved );
                        }
                    }
                    if( oplogReader.awaitCapable() && tailing )
                        okResultCode = 0; // don't sleep
                    //syncedTo设置时间戳，保存从结点的更新时间，用于下次从结点需要查询新的oplog时，
                    //它使用“syncedTo”获得它需要的新的oplog，或者用于发现它已经out-of-sync。
                    syncedTo = nextOpTime;
                    save(); // note how far we are synced up to now
                    log() << "repl:   applied " << n << " operations" << endl;
                    nApplied = n;
                    log() << "repl:  end sync_pullOpLog syncedTo: " << syncedTo.toStringLong() << endl;
                    break;
                }
                else {
                }
                .....
                BSONObj op = oplogReader.next();

                unsigned b = replApplyBatchSize;
                bool justOne = b == 1;
                scoped_ptr<writelock> lk( justOne ? 0 : new writelock() );
                while( 1 ) {

                    BSONElement ts = op.getField("ts");
                    //类型异常判断
                    if( !( ts.type() == Date || ts.type() == Timestamp ) ) {
                        log() << "sync error: problem querying remote oplog record" << endl;
                        log() << "op: " << op.toString() << endl;
                        log() << "halting replication" << endl;
                        replInfo = replAllDead = "sync error: no ts found querying remote oplog record";
                        throw SyncException();
                    }
                    OpTime last = nextOpTime;
                    nextOpTime = OpTime( ts.date() );
                    //当上次操作时间比下一次操作时间要更晚，表示cap collection发生了前部数据被overwrite的情况
                    //这时系统会执行resync,相关问题参见:
                    //http://www.snailinaturtleneck.com/blog/2010/10/14/getting-to-know-your-oplog/
                    if ( !( last < nextOpTime ) ) {
                        log() << "sync error: last applied optime at slave >= nextOpTime from master" << endl;
                        log() << " last:       " << last.toStringLong() << endl;
                        log() << " nextOpTime: " << nextOpTime.toStringLong() << endl;
                        log() << " halting replication" << endl;
                        replInfo = replAllDead = "sync error last >= nextOpTime";
                        uassert( 10123 , "replication error last applied optime at slave >= nextOpTime from master", false);
                    }
                    //在从结点中指定一个从主结点中申请操作的延迟时间（单位是秒）。
                    //这使得构造一个delayed slaves变得容易。假如用户意外地删了重要的文档或者插入了坏的数据，这些操作都会复制到所有的从结点中。依靠delaying应用程序的操作，你将有可能从错误的操作中恢复。
                    if ( replSettings.slavedelay && ( unsigned( time( 0 ) ) < nextOpTime.getSecs() + replSettings.slavedelay ) ) {
                        assert( justOne );
                        oplogReader.putBack( op );
                        //设置sleep时间
                        _sleepAdviceTime = nextOpTime.getSecs() + replSettings.slavedelay + 1;
                        dblock lk;
                        if ( n > 0 ) {
                            //syncedTo设置时间戳，保存从结点的更新时间，用于下次从结点需要查询新的oplog时，
                            //它使用“syncedTo”获得它需要的新的oplog，或者用于发现它已经out-of-sync。
                            syncedTo = last;
                            save();
                        }
                        log() << "repl:   applied " << n << " operations" << endl;
                        log() << "repl:   syncedTo: " << syncedTo.toStringLong() << endl;
                        log() << "waiting until: " << _sleepAdviceTime << " to continue" << endl;
                        return okResultCode;
                    }

                    sync_pullOpLog_applyOperation(op, &localLogTail, !justOne);
                    n++;

                    if( --b == 0 )
                        break;
                    // if to here, we are doing mulpile applications in a singel write lock acquisition
                    if( !oplogReader.moreInCurrentBatch() ) {
                        // break if no more in batch so we release lock while reading from the master
                        break;
                    }
                    op = oplogReader.next();

                    getDur().commitIfNeeded();
                }
            }
        }

        return okResultCode;
    }

   上面方法代码比较长，首先它会初始要链接的master的oplog名空间信息，之后尝试链接到master上以获取相应的cursor id信息。该cursor id用于标识当前slave访问master时所使用的cursor(因为master中的oplog cursor会在返回oplog信息时不关闭，它支持下次slave链接使用该cursor时从相应的pos位置继续获取。这块内容可以参见这篇文章 Mongodb源码分析--Replication之主从模式--Master).

   如果cursorid正常，则使用oplogReader对象来获取相应的oplog信息(注：oplogReader为mongodb为了查询oplog而声明的一个类，详情参见其源码文件oplogreader.h)

   除此以外，上面方法还会设置本地的syncedTo来记录下次同步时使用的时间戳。同时根据本地保存的时间戳与oplogReader所返回的master oplog信息中的ts进行比较，以判断是否出现out of sync的情况，以进而执行resync操作。有关这类逻辑说明参见上面的代码注释即可。

   当获取的master oplog符合（本地时间戳）要求时，则将oplog对象进行分解，以进而将其中的数据对象保存到本地并执行持久化操作（上面代码段：getDur().commitIfNeeded()）。这里要说明的是，将oplog进行分解时执行的逻辑通过sync_pullOpLog_applyOperation方法中执行，因为这里牵扯到oplog的数据结构，由于篇幅所限，这部分内容我会在后面章节中进行说明，我们只要知道在分解结束后，最终调用如下方法将数据放到本机上：

   //repl.cpp
    void ReplSource::applyOperation(const BSONObj& op) {

    //oplog.cpp
    void applyOperation_inlock(const BSONObj& op , bool fromRepl ) {
        OpCounters * opCounters = fromRepl ? &replOpCounters : &globalOpCounters;

        if( logLevel >= 6 )
            log() << "applying op: " << op << endl;

        assertInWriteLock();

        OpDebug debug;
        BSONObj o = op.getObjectField("o");//实际操作的document
        const char *ns = op.getStringField("ns");
        // operation type -- see logOp() comments for types
        const char *opType = op.getStringField("op");

        if ( *opType == 'i' ) {//插入
            opCounters->gotInsert();

            const char *p = strchr(ns, '.');
            if ( p && strcmp(p, ".system.indexes") == 0 ) {
                // updates aren't allowed for indexes -- so we will do a regular insert. if index already
                // exists, that is ok.
                theDataFileMgr.insert(ns, (void*) o.objdata(), o.objsize());
            }
            else {
                // do upserts for inserts as we might get replayed more than once
                BSONElement _id;
                if( !o.getObjectID(_id) ) {
                    /* No _id.  This will be very slow. */
                    Timer t;
                    updateObjects(ns, o, o, true, false, false , debug );
                    if( t.millis() >= 2 ) {
                        RARELY OCCASIONALLY log() << "warning, repl doing slow updates (no _id field) for " << ns << endl;
                    }
                }
                else {
                    BSONObjBuilder b;
                    b.append(_id);

                    RARELY ensureHaveIdIndex(ns); // otherwise updates will be slow

                    updateObjects(ns, o, b.done(), true, false, false , debug );
                }
            }
        }
        else if ( *opType == 'u' ) {//更新
            opCounters->gotUpdate();

            RARELY ensureHaveIdIndex(ns); // otherwise updates will be super slow
            updateObjects(ns, o, op.getObjectField("o2"), /*upsert*/ op.getBoolField("b"), /*multi*/ false, /*logop*/ false , debug );
        }
        else if ( *opType == 'd' ) {//删除
            opCounters->gotDelete();

            if ( opType[1] == 0 )
                deleteObjects(ns, o, op.getBoolField("b"));
            else
                assert( opType[1] == 'b' ); // "db" advertisement
        }
        else if ( *opType == 'n' ) {//无操作
            // no op
        }
        else if ( *opType == 'c' ) {//command
            opCounters->gotCommand();

            BufBuilder bb;
            BSONObjBuilder ob;
            _runCommands(ns, o, bb, ob, true, 0);
        }
        else {
            stringstream ss;
            ss << "unknown opType [" << opType << "]";
            throw MsgAssertionException( 13141 , ss.str() );
        }
    }

到这里，关于如何进行crud的操作，就与我之前的几篇文章的内容关联上了，大家回顾一下即可。最后用一次时序图来回顾一下slave的执行流程：

好了，今天的内容到这里就告一段落了。

原文链接:http://www.cnblogs.com/daizhj/archive/2011/06/20/mongodb_sourcecode_repl_slave_run.html
    作者: daizhj, 代震军
    微博: http://t.sina.com.cn/daizhj
    Tags: mongodb,c++,Replica,master-slave

本文链接

这样的“牛”人最好别碰上

2011-06-17T03:27:00Z

很久没写口水文了，因为一直没有像样的话题。另外作为一个技术从业者，写那类东东实在没什么意思。但昨天与公司销售一起去一家客户那做技术交流的过程中发现了技术之外的话题，我想很多公司可能也正在上演以这类话题所引发的冲突，所以就一并以流水帐的方式呈现出来了。

因为这次是客户那边的CTO对我们产品有疑问，所以之前我们早早准备了一些资料和相关测试说明文档，希望能全方位的介绍一下我们产品特别是企业版的细节和应用场景。这里要说明的是因为这家公司在过去不到一年的时间里因为技术和商务那边内耗过重，经历了两轮大的人事变动，基本上技术部门人员流失怠尽，而早期与我们接触的技术人员已全部离任。

而最近这家公司又新上来一名CTO，据他们内部人员说，这位CTO之前在一家杀毒软件公司工作，且刚上任不到一个月已把手下的技术人员骂了一个遍（具体骂的什么东东，后面会提到）。因为是CTO要出席这次交流，我们提前就到了那家公司。

在与他们的商务做了简单的沟通和介绍（我们公司的销售部负责人这次也去了）之后，就开始了大近半个多小时的等待（感觉就像在等某部委的领导似的）。其间他们运营部门主管先到，介绍了一下他们的问题，只说我们的企业版未能达到他们的要求。出于本职工作要求，我希望他能具体说一下产品到地底那方面有了问题，他说是并发访问有问题。考虑到他说他们也进行了测试，所以就想深入探讨一下他们的测试流程，用例场景等情况，这一问不要紧，那位运营人员一问三不知(甚至连用的压力测试工具都不太清楚 )，最后他敷衍的说是CTO提出来的，可以等他来后进一步沟通。

在等了近半个多小时后，这位CTO终于大驾显身。一进来就问旁边的商务人员有没有带录音笔（开始我有些奇怪，以为是技术交流作备案用，但真正的目的后来才明白），然后所谓的“交流”就开始了。因为他们的商务之前与我们沟通时说这位CTO 可能是做技术太久了，对于人情事故不是太在意，希望我们在听他说话时不要打断他谈话，别外也不要直接与其产生冲突或顶撞，言外之意就是一味点头称是就行了（这一点我们后来也是尽量按他说的办,只当他是金正日这类北朝鲜政府官员就得了呗）。

在这位CTO说完了之后，我们明白了他的意思是---我们产品3.1版能解决的问题，只要改一下索引就可以了，为什么还要让他们买企业版。这不是存心骗他们吗！因为这位CTO在优化我们产品时发现有索引创建未使用的情况，就这一点我把我们产品开发流程做了一下解释：因为有些索引为了某些功能而建的，这个功能可能当前版本未加入（可能性能不稳定或新版本未将该功能作为主打功能），在团队开发人员协作时未及时同步这类情况或发生代码版本的覆盖，导致这类情况发生，但我们往往会在后续版本中以升级包的形式修正这类问题。（上面红字是我当时的解析），但这位CTO显然对这个解释不满意。另外我也询问了他们测试我们产品、特别是企业版的工具和测试用例情况，但这位CTO仅以一句告之“我没说这件事”，这让我当时一头雾水，必定你们的运营人员说测试结果不能满足要求呀，为什么突然变成了“索引问题”了呢，莫非你们一开始就没测试企业版，而仅以我们一年半以前的一个老版本进行测试，然后就说我们的产品在骗钱，更何况这类索引问题我们在3.1之后就已修正过了？即使跳跃式思维也没这么跳的呀。没办法，我也只能无奈的与这位CTO 转而交流索引问题。

我把一些大站使用我们产品的情况做了一下介绍，特别说明了在1台WEB+DB的情况下，解决高并发的可行性很底（两万以上在线用户同时并发操作），如果真有这种银弹，我们也不用费心开发企业版了，因为后者才是以水平扩展的方式分布式布署产品来解决这类问题的。而这位CTO好像就像没听进去一样，说他以前做过论坛（注意：他们的商务说他之前在一家杀毒软件公司工作，而他所说的那个论坛具我所知也并不怎么地，asp写得功能少得与留言板有得一拼），所以不用说我们的方案如何如何，总之言外之意就是骗他们钱似的。到这里我也真是无语了，我做论坛有5年多了，虽不敢说是专业，但也不是什么门外汉。主流网站所用的技术（缓存，负载远程，读写分离，再到NOSQL数据库等）均研究涉列过，其中的熟轻熟重心里还是有数的。我们的方案也是参照公司主流产品DZ的方案基本上发展起来的，并且已在一些大站上使用，效果很好。而面前这位CTO却如是说，叫人情何以堪呢。当问到企业版那块有问题时，他的回答让我更是瞠目结舌：“你们为什么要用MEMCACHED,谁都知道它的效率低，sina还搞出来个memcachedb（言外之意-不值一提），你们为什么不自己写一个”。

我的回答是：“我知道MEMCACHED目前是旧了一些（从发布时间来看），但也不想你想的那般差，另外我们产品在分布式缓存上是支持几种使用场景的，比如redis,ttserver，我们都支持。当初我们这样设计就考虑到有些公司使用的缓存产品不一样，所以提供了这种自助餐似的方式，让不同的公司根据自己的技术平台体系进行选择，而经我们测试memcached在window平台上也可以工作的很出色（而贵公司的web系统也是基于windows平台），所以才使用它。而我们公司的开发人员配置有限，不可能再抽人去写一个key/value缓存产品（况且即使写出来，如果没有1到2个版本的积累和测试，一上来就去给用户去用，这也是不负责任的），况且目前真正研究这类产品的都是一些大型的公司，而这些公司研发的目的也是不尽相同的，因为它们的业务场景不同。有偏数据缓存，也有偏数据存储，或兼而有之。从memcached，ttserver， redis, 以及couchdb,mongodb，都是如此。即使我们写出了类似memcached的产品，但到客户那里因为其各式各样的运营需求，不适应的情况再所难免。”

其实我想这类问题在一些公司很常见，大家是否在遇到过维护别人代码时有想重新写一遍的冲动，但这时的冲动多数就是魔鬼，因为只有写过相关产品的人才知道为什么产品是这个样子，比如分布式应用中的CAP原则及paxos算法，这类问题和知识平时做普遍产品开发的根本就用不上（这也就是行业经验和业务背景为什么重要的原因）。而动不动就去重复发明轮子，你可以说玩技术练手，但在公司眼里就是在玩钱，起码一般的公司不要让你这般随意瞎玩。

最无厘头的是，这位CTO还言语威胁说，如果我们不同意他的意见（包括我们想骗他们钱的事），就会把我们的照片发到博上去，真是无语了。他还说什么找一个60万粉丝的微博发上来，大家就出名了。真是太搞笑了，发微博可不是轮坛发帖子那样，你也得先搞一个百万级粉丝帐号再说不迟。我心想即使发出来，最终被嘲笑的是谁还不一定呢。就在他拿着IPHONE4在我们面前假装拍照而晃来晃去时，我想碰到这样的用户，真是对乔(布斯)帮主的亵渎。（另外这里打一个软广告，我们的企业版会在3.9这个版本中进行开源，相关的安装，设计文档及测试报告链接也会一并奉上，到时谁在糊弄一看便之，呵呵）

会议期间我们的商务也出来说，因为双方有合同在前，所以如果这时贵方单方解约，要负相关责任时，这位CTO满不在乎，难怪他之前一进门就要录音笔，原来已做了类似取证的打算，但可以说他的这个目的落空了。最后结果大家也猜的出来，不欢而散呗！

出了他们公司时，想起之前商务说这位CTO认为自己很“牛”，但也没想到一个人可以“牛”成这样。会上我听到最多的他形容手下技术人员的词语，这三个词名列前茅：“白痴，饭桶，笨蛋”。而最尴尬的就是他的一名下属就在他的旁边，在外人面前直接这样批评下属真是闻所未闻，让这位下属情何以堪。况且真正的牛人我也不是没共过事，比如写超级解霸的梁肇新，目前所在公司的戴志康。无论哪个人都是对问题就事论事，决不搞这种人身攻击，必定身居高位是要让手下为自己卖力，而不是让手下整天被你喷来喷去的。做人做到这份上，真不知道是成功还是失败。

本不想再为这个(类)人再多费笔墨，但想到如果是刚出道没几年的程序员或技术人员碰到这样的CTO或Leader会怎么样，难道只能感叹自己的“悲催”命运。不，决不是这样！请相信这时你真没必要再把他看作牛人、甚至人来看。因为不懂得人情世故，只顾自恋，自傲，认为自己是牛B，别人是傻B的人，只能把这类人当牛看了。这类人有很强的自我倾向，你无论说什么基本上都被当做耳旁风来刮，只认自己的技术背景而顾步自封，谁都不放在眼里。如果这样的人是技术人员充其量只能污染他身边同事及所在部门，如果是是在CTO岗位的话，就是在毁掉这个公司了。而如果是后者，那多待无益。

有句名言：“不服高人有罪”，但这样的“牛”人还是少碰上为好。

希望看这篇文章时没有过多占用你的时间，或影响你看到本文之前的好心情，必定又到周未了嘛，呵呵:)

最后友情提示：动物凶猛，小心提防。

原文链接：http://www.cnblogs.com/daizhj/archive/2011/06/17/2083441.html
作者:代震军
微博: http://t.sina.com.cn/daizhj

本文链接

Mongodb源码分析--Replication之主从模式--Master

2011-06-13T04:47:00Z

    mongodb中提供了复制(Replication)机制，通过该机制可以帮助我们很容易实现读写分离方案，并支持灾难恢复（服务器断电）等意外情况下的数据安全。

      在老版本(1.6)中，Mongo提供了两种方式的复制：master-slave及replica pair模式（注:mongodb最新支持的replset复制集方式可看成是pair的升级版，它解决pair只能在两个结点间同步的限制，支持多个结点同步且支持主从宕机时的自动切换, 在1.6版以后提供）。


      利用前者，我们可以实现读写分离（主从复制模式），后者则支持当主服务器断电情况下的集群中其它slave自动接管，并升级为主服务器。并且如果后来的也出错了，那么master状态将会转回给第一个服务器（之前宕机但后来又恢复运行的服务器）。

同时mongodb支持使用安全认证（enable）。不管哪种replicate方式，只要在master/slave中创建一个能为各个database认识的用户名/密码即可。其认证过程如下：

slave先在local.system.users里查找一个名为"repl"的用户，找到后用它去认证master。如果"repl"用户没有找到，则使用local.system.users中的第一个用户去认证。local数据库和admin数据库一样，local中的用户可以访问整个db server。

   下面介绍分别介绍一下这两种复制的配置方式：

   Master-Slave(主从)模式:
   一个server可以同时为master和slave。一个slave可以有多个master（不推荐，可能会产生不可预期的结果）。

     配置选项：
   --master 以主服务器方式启动
   --slave   以从服务器方式启动
     --autoresync：自动重新sync，因为该操作会copy 主服务器上的所有document，比较耗时，在10分钟内最多只会进行一次。
   --oplogSize：指定master上用于存放更改的数据量，如果不指定，在32位机上最少为50M，在64位机上最少为 1G，最大为磁盘空间的5%。
   --source 主服务器地址（与--slave组合使用）
   --only    仅限于同步指定数据库（下面示例为test库）
   --slavedelay 同步延时

   下面是本人在本地为了测试方便所使用的配置参数
        Master: IP->10.0.1.103

mongod --dbpath=d:\mongodb\db --master --oplogSize 64

Slave: IP->10.0.4.210

mongod --dbpath=d:\mongodb\db --slave --source 10.0.1.103:27017 --only test --slavedelay 100

    补充：受限的master-master复制，这种模式对插入、查询及根据_id进行的删除操作都是安全的。但对同一对象的并发更新无法进行。Mongo 不支持完全的master-master复制，通常情况下不推荐使用master-master模式，但在一些特定的情况下master-master也可用。master-master也只支持最终一致性。配置master-master只需运行mongod时同时加上--master选项和 --slave选项。如下：
     mongod --dbpath=d:\mongodb\db --port 27017 --master --slave --source localhost:27018
     mongod --dbpath=d:\mongodb\db --port 27018 --master --slave --source localhost:27017

    Replica pairs模式
     以这种方式启动后，数据库会自动协商谁是master谁是slave。一旦一个数据库服务器断电，另一个会自动接管，并从那一刻起起为master。万一另一个将来也出错了，那么master状态将会转回给第一个服务器。以这种复制方式启动mongod的命令如下：
     配置选项：
      mongod --pairwith <remoteserver> --arbiter <arbiterserver>
      --pairwith: remoteserver是pair里的另一个server
      --arbiter: arbiterserver是一个起仲裁作用的Mongo数据库，用来协商pair中哪一个是master。arbiter运行在第三个机器上，利用“平分决胜制”决定在pair中的两台机器不能联系上对方时让哪一个做master，一般是能同arbiter通话的那台机器做master。如果不加--arbiter选项，出现网络问题时两台机器都作为master。
      注：可使用db.$cmd.findOne({ismaster:1})可以检查当前哪一个database是master。

     另外这种模式下的两台机器只能满足最终一致性。当replica pair中的一台机器完全挂掉时，需要用一台新的来代替。如(n1, n2)中的n2挂掉，这时用n3来代替n2。步骤如下：
      1. 告诉n1用n3来代替n2：db.$cmd.findOne({replacepeer:1});
      2. 重启n1让它同n3对话：mongod --pairwith n3 --arbiter <arbiterserver>
      3. 启动n3：mongod --pairwith n1 --arbiter <arbiterserver>。
     在n3的数据没有同步到n1前n3还不能做master，这个过程长短由数据量的多少决定。


     了解了复制模式之后，还有一个问题需要介绍一下，不是就是本文中mongodb使用cap collection来存储操作日志，并进而使用日志来复制(同步)结点间的数据，其中由主结点保存的操作的记录叫做oplog(operation log的简称)。

   Oplog存在一个叫local的特殊数据库中，在oplog.$main集合。Oplog中的每一个文档表示一个在主结点上执行的操作。文档主要包括4块内容，如下：

Ts:操作的时间戳。时间戳类型是一个用来跟踪操作是何时执行的一种内部类型。它由4字节的时间戳和四字节的增量计数器组成。
Op:执行的操作的类型，大小为1字节。（例如，“i”代表insert,"u":update, "d":delete, "n":none无操作等）
Ns：执行操作的命名空间（集合名）
O：执行操作的文档。对于插入，这是将要插入的文档。

     另外这种日志只保存会“改变数据库状态”的操作。查询操作不会记录在oplog中。

   好了，了解这些知识之后，我们就来开始看一下如何调试master-slave模式的源码，首先要在vs2010中打开mongod项目，并将启动参数中设置如下：
      --master --oplogSize 64   （master IP为10.0.1.103）

     如下图:



     之后编译该项目，启动该主服务结点，如下：



     接着我们可以在本地或另外一台机器上启动一个slave结点：

mongod --dbpath=d:\mongodb\db --slave --source 10.0.1.103:27017 --only test --slavedelay 100

下面介绍一下master（主服务端）的代码执行流程。首先我们打开instance.cpp文件，找到下面方法：

    //instance.cpp
    // Returns false when request includes 'end'
    void assembleResponse( Message &m, DbResponse &dbresponse, const SockAddr &client ) {
    ......
       if ( op == dbQuery ) {
            if ( handlePossibleShardedMessage( m , &dbresponse ) )
                return;
            receivedQuery(c , dbresponse, m );
        }
        //服务端(master) 收到message执行相关查询操作
        else if ( op == dbGetMore ) {
            if ( ! receivedGetMore(dbresponse, m, currentOp) )
                log = true;
        }
    .....
    }

   看过本系列开头那几篇BLOG的朋友，会看出上面方法其实在mongodb的crud操作中都会执行到，更多内容可以参见这篇BLOG，这里不再赘述。

   当slave 从结点发送同步复制请求时，master会执行上面的dbGetMore操作，从主库中的oplog中获取相应日志并返回给slave结点，下面是receivedGetMore()方法的具体实现：

     //instance.cpp
     bool receivedGetMore(DbResponse& dbresponse, Message& m, CurOp& curop ) {
        StringBuilder& ss = curop.debug().str;
        bool ok = true;

        //参见：Mongodb源码分析--消息(message)中的查询更多(document)消息结构相关内容
        //http://www.cnblogs.com/daizhj/archive/2011/04/02/2003335.html
        DbMessage d(m);
        //完整的集合名称，形如:"dbname.collectionname"
        const char *ns = d.getns();
        //返回的document数
        int ntoreturn = d.pullInt();
        //在REPLY消息中的Cursor标识符，其必须来自于数据库
        long long cursorid = d.pullInt64();

        ss << ns << " cid:" << cursorid;
        if( ntoreturn )
            ss << " ntoreturn:" << ntoreturn;

        time_t start = 0;
        int pass = 0;
        bool exhaust = false;
        QueryResult* msgdata;//查询结果
        while( 1 ) {
            try {
                readlock lk;
                Client::Context ctx(ns);
                //执行GetMore查询
                msgdata = processGetMore(ns, ntoreturn, cursorid, curop, pass, exhaust);
            }
            catch ( GetMoreWaitException& ) {
                exhaust = false;
                massert(13073, "shutting down", !inShutdown() );
                if( pass == 0 ) {
                    start = time(0);
                }
                else {
                    if( time(0) - start >= 4 ) {
                        // after about 4 seconds, return.  this is a sanity check.  pass stops at 1000 normally
                        // for DEV this helps and also if sleep is highly inaccurate on a platform.  we want to
                        // return occasionally so slave can checkpoint.
                        pass = 10000;
                    }
                }
                pass++;
                DEV
                sleepmillis(20);
                else
                    sleepmillis(2);
                continue;
            }
            catch ( AssertionException& e ) {
                exhaust = false;
                ss << " exception " << e.toString();
                msgdata = emptyMoreResult(cursorid);
                ok = false;
            }
            break;
        };
        //将查询结果集绑定到message对象
        Message *resp = new Message();
        resp->setData(msgdata, true);
        ss << " bytes:" << resp->header()->dataLen();
        ss << " nreturned:" << msgdata->nReturned;
        //将上面的消息对象指针绑定到dbresponse
        dbresponse.response = resp;
        dbresponse.responseTo = m.header()->id;
        if( exhaust ) {
            ss << " exhaust ";
            dbresponse.exhaust = ns;
        }
        return ok;
    }

可以看出，通过对message的解析找出相应的cursorid，因为mongodb如果发现游标为tailable(类型)时，会cache该cursor而不是关闭它，这主要是考虑到当下次slave请求来时，直接从cache中获取该cursor以提升效率并用它来作为继续获取后续oplog操作信息。上面方法在执行结束处会将获取到的oplog结果封装到message中并返回。但其如何获取，就要分析下面方法了：

    //query.cpp
     QueryResult* processGetMore(const char *ns, int ntoreturn, long long cursorid , CurOp& curop, int pass, bool& exhaust ) {
        exhaust = false;
        //在map<CursorId, ClientCursor*>中查询相应游客信息
        ClientCursor::Pointer p(cursorid);
        //将结果返回（可能没找到）
        ClientCursor *cc = p.c();

        int bufSize = 512;
        if ( cc ) {
            bufSize += sizeof( QueryResult );
            bufSize += MaxBytesToReturnToClientAtOnce;
        }
        //创建收集查询记录结果的buf对象
        BufBuilder b( bufSize );
        //跳过预留数据区间（QueryResult）
        b.skip(sizeof(QueryResult));

        int resultFlags = ResultFlag_AwaitCapable;
        int start = 0;
        int n = 0;
        //判断cc是否有效(如未找到则无效)
        if ( !cc ) {
            log() << "getMore: cursorid not found " << ns << " " << cursorid << endl;
            cursorid = 0;
            resultFlags = ResultFlag_CursorNotFound;
        }
        else {
            //更新master结点local.slaves中的相应信息（包括lastop时间戳）
            //注：主结点使用存储在local.slaves中的syncedTo来跟踪多少slave是已经更新的。
            if ( pass == 0 )
                cc->updateSlaveLocation( curop );

            int queryOptions = cc->queryOptions();

            if( pass == 0 ) {
                StringBuilder& ss = curop.debug().str;
                ss << " getMore: " << cc->query().toString() << " ";
            }
            //获取相应cursor，以便while遍历
            start = cc->pos();
            Cursor *c = cc->c();
            c->checkLocation();
            DiskLoc last;

            scoped_ptr<Projection::KeyOnly> keyFieldsOnly;
            if ( cc->modifiedKeys() == false && cc->isMultiKey() == false && cc->fields )
                keyFieldsOnly.reset( cc->fields->checkKey( cc->indexKeyPattern() ) );
            //遍历cursor，找到并封装相应查询结果给buf对象
            while ( 1 ) {
                if ( !c->ok() ) {//到结尾
                    if ( c->tailable() ) {//处理tailable情况
                        //Tailable 表示在返回最后一条数据后，不要关闭当前 cursor。
                        //这是因为系统考虑到稍后你可以再次使用该cursor.
                        /* when a tailable cursor hits "EOF", ok() goes false, and current() is null.  however
                           advance() can still be retries as a reactivation attempt.  when there is new data, it will
                           return true.  that's what we are doing here.
                           */
                        if ( c->advance() )
                            continue;

                        if( n == 0 && (queryOptions & QueryOption_AwaitData) && pass < 1000 ) {
                            throw GetMoreWaitException();
                        }

                        break;
                    }
                    //释放cursor资源关闭它（执行delete操作）
                    p.release();
                    bool ok = ClientCursor::erase(cursorid);
                    assert(ok);
                    cursorid = 0;
                    cc = 0;
                    break;
                }
                // 如果是clone collection时，则不会匹配

// If match succeeds on index key, then attempt to match full document.

                if ( c->matcher() && !c->matcher()->matches(c->currKey(), c->currLoc() ) ) {
                }
                /*
                  TODO
                else if ( _chunkMatcher && ! _chunkMatcher->belongsToMe( c->currKey(), c->currLoc() ) ){
                    cout << "TEMP skipping un-owned chunk: " << c->current() << endl;
                }
                */
                else {//值是否重复
                    if( c->getsetdup(c->currLoc()) ) {
                        //out() << "  but it's a dup \n";
                    }
                    else {//如匹配
                        last = c->currLoc();
                        n++;
                        //装填数据到buf中
                        if ( keyFieldsOnly ) {
                            fillQueryResultFromObj(b, 0, keyFieldsOnly->hydrate( c->currKey() ) );
                        }
                        else {
                            BSONObj js = c->current();
                            // show disk loc should be part of the main query, not in an $or clause, so this should be ok
                            fillQueryResultFromObj(b, cc->fields.get(), js, ( cc->pq.get() && cc->pq->showDiskLoc() ? &last : 0));
                        }

                        if ( ( ntoreturn && n >= ntoreturn ) || b.len() > MaxBytesToReturnToClientAtOnce ) {
                            c->advance();
                            cc->incPos( n );
                            break;
                        }
                    }
                }
                //指向下一条记录
                c->advance();

                if ( ! cc->yieldSometimes() ) {
                    cc = 0;
                    break;
                }
            }

            if ( cc ) {
                cc->updateLocation();
                cc->mayUpgradeStorage();
                //用last中的optime 更新_slaveReadTill
                cc->storeOpForSlave( last );
                exhaust = cc->queryOptions() & QueryOption_Exhaust;
            }
        }
        //将buf中的信息绑定到查询结果集
        QueryResult *qr = (QueryResult *) b.buf();
        qr->len = b.len();
        qr->setOperation(opReply);
        qr->_resultFlags() = resultFlags;
        qr->cursorId = cursorid;
        qr->startingFrom = start;
        qr->nReturned = n;
        b.decouple();

        return qr;
    }

上面代码有些长，但其目的很明确，就是针对指定的cursor进行遍历。这里mongodb会为每个slave保存一个cursor，并且其在遍历完成后将最后一条oplog的时间戳作为当前slave在local.slaves中的更新标识信息(syncedTo)，来标识当前slave的更新情况。（注：首次同步时全部复制会执行copyDatabase，复制master db上的所有document）。该方法运行截图如下：

另外需要解释的是，master结点貌似并不会使用slave发来的syncedTo来过滤capped collection中的旧oplog(指小于syncedTo时间戳)的数据，而是使用tailable类型的cursor来解决如果持续获取后续新增oplog操作信息。前者的主观臆测让我在源码中兜了一个圈子，因为我一直主观认为mongod会执行类似查询操作来过滤相应旧oplog的时间戳信息，并将结果集返回给slave端。现在看来master只是不断返回后续添加到cap collection中oplog（有可能是out of sync的情况而引发slave地点执行resync操作），而最终的过滤判断操作完全交给了slave端。这一点会在我下一篇文章中有所介绍。

好了，今天的内容到这里就告一段落了。在接下来的文章中，将会介绍slave端是如何发起同步操作，以及最终如何使用获取到的oplog来构造本机数据的。

参考链接：

http://www.mongodb.org/display/DOCS/Replication

http://www.mongodb.org/display/DOCS/Master+Slave

    http://www.snailinaturtleneck.com/blog/2010/10/12/replication-internals/
   http://www.snailinaturtleneck.com/blog/2010/10/14/getting-to-know-your-oplog/
   http://www.snailinaturtleneck.com/blog/2010/08/02/replica-sets-part-2-what-are-replica-sets/

   原文链接:http://www.cnblogs.com/daizhj/archive/2011/06/13/mongodb_sourcecode_repl_master_run.html
    作者: daizhj, 代震军
    微博: http://t.sina.com.cn/daizhj
    Tags: mongodb,c++,Replica,master-slave

本文链接

Mongodb源码分析--链接池(ConnPool)

2011-06-07T01:03:00Z

    在之前的一篇文章中，介绍了mongos的balaner的执行流程，其中在源码中的Balancer::run()方法里简单说明了为了连接到configserver，balancer通过构造ScopedDbConnection实现来链接并执行相应操作，因为当时篇幅所限，只是该链接使用池化的方式一带而过，今天就专门介绍一下mongodb中使用池化方式来管理链接对象以提升链接效率的原理。

   好了，开始今天的正文吧！

   首先看一下balancer类的run()方法，相关代码如下：

    //balance.cpp
    void Balancer::run() {
        ......
        while ( ! inShutdown() ) {//一直循环直到程序中断或关闭

            try {
                ......

                ScopedDbConnection conn( config );

                ......

                conn.done();//将conn放到链接池中(为其它后续操作使用)

                sleepsecs( _balancedLastTime ? 5 : 10 );
            }
            catch ( std::exception& e ) {
                ......
            }
        }
    }

上面方法中从ScopedDbConnection声明到该实现执行done()方法结束，系统会从链接池中获取一个链接对象，如无链接则直接创建。如果是创建的链接，则会将该链接添加到池中。下面我们就看一下其类图：

图中的红框所圈的类均为connpool.h头文件中所包含定义的类信息，而这些类中（比如ScopedDbConnection，上面代码提到过）会包含一个DBClientBase属性指针，而DBClientBase的定义位于dbclient.h头文件中，其主要是定义了客户端连接到mongodb服务端时所经常进行的操作（CRUD等）。

图中的类比较多，主要的几个包括：

    ScopedDbConnection：池中的数据库链接类，其通过持有的DBClientBase指出针来施加crud操作
    DBConnectionPool：数据库链接池类，定义链接的创建，获取，flush，以及维护等操作。
    PoolForHost：该对象提供以栈式(stack)方式管理pool链接对象。

下面就先看一下ScopedDbConnection的构造方法，其执行流程如下：

    //connpool.cpp
    ScopedDbConnection::ScopedDbConnection(const Shard& shard )
        : _host( shard.getConnString() ) , _conn( pool.get(_host) ) {
    }

其中的_host( shard.getConnString() )只是将要链接的mongo服务地址绑定到ScopedDbConnection的_host属性上。重要的是_conn( pool.get(_host)）这一行代码，它会从池中（pool类型为DBConnectionPool）获取一个链接，如池中没有则会创建一个链接并返回，如下（详情见注释）：

    //connpool.cpp
    DBClientBase* DBConnectionPool::get(const ConnectionString& url) {
        // 从池中获取一个链接对象
        DBClientBase * c = _get( url.toString() );
        //如获取到则直接返回
        if ( c ) {
            onHandedOut( c );//执行取出时定义的hook方法
            return c;
        }

        string errmsg;
        c = url.connect( errmsg );
        uassert( 13328 ,  _name + ": connect failed " + url.toString() + " : " + errmsg , c );
        //以url为链接地址，构造一个链接对象并返回该对象
        return _finishCreate( url.toString() , c );
    }

上面方法中_get( url.toString() ) 这一行代码主要是用于执行从池中获取对象的操作，它的实现代码如下：

    DBClientBase* DBConnectionPool::_get(const string& ident) {
        scoped_lock L(_mutex);
        PoolForHost& p = _pools[ident];//获取指定的链接池
        return p.get();
    }

其中_pools类型定义如下，用于实现从“服务器名称”到“相应链接池”的映射，因为不同的服务器会对应不同的链接池：

typedef map<string,PoolForHost,serverNameCompare> PoolMap;

找到了相应的链接池之后，返回该池所对应的PoolForHost对象的引用，该对象提供以栈式(stack)方式管理pool链接对象。其get()方法定义如下：

    //connpool.cpp
    DBClientBase * PoolForHost::get() {
        time_t now = time(0);

        while ( ! _pool.empty() ) {
            StoredConnection sc = _pool.top();//取出栈顶链接
            _pool.pop();//移除栈顶的元素
            if ( sc.ok( now ) )//如链接空闲未超过1小时
                return sc.conn;
            delete sc.conn; //释放链接对象
        }
        return NULL;//如无有效链接，则返回null
    }

现在我们再将注意力放回到主流程DBClientBase* DBConnectionPool::get(const ConnectionString& url)方法的下面一行代码，即：

    //connpool.cpp
    //如获取到则直接返回
    if ( c ) {
            onHandedOut( c );//执行取出时定义的hook方法
            return c;
    }

   该方法一个hook方法的调用，它的实现方式有些复杂，很像设置模式中的Observer （观察者）模式，我们先看一下该模式的类图：



   有关该模式的具体讲解可以参见相关资料或在google上搜一下，这里暂不做解释了。

   这里我们先看一下该方法的具体实现（onCreate与onHandedOut方式类似，这里仅对onHandedOut进行说明）：

void DBConnectionPool::onHandedOut( DBClientBase * conn ) {
        if ( _hooks.size() == 0 )
            return;

        for ( list<DBConnectionHook*>::iterator i = _hooks.begin(); i != _hooks.end(); i++ ) {
            (*i)->onHandedOut( conn );
        }
    }

可以看出，它进而面使用了for的方式，依次对conn进行onHandedOut（）方法处理，而_hooks的定义如下：

    //connpool.h 文件
    //hooks列表，用于收集hook方法并(批量)执行相关方法
    list<DBConnectionHook*> _hooks;

看到这里，我们有必要了解一下_hooks是如何添加相关hook对象的。还记得我在这篇文章中介绍在mongos的main（）中有如下代码吗？

    //server.cpp
    // set some global state
    //添加对链接池hook的绑定(shardingConnectionHook对象引用)，以最终调用其onHandedOut方法
    pool.addHook( &shardingConnectionHook );
    //设置链接池名称
    pool.setName( "mongos connectionpool" );

对了，就是上面的addHook()方法，添加了对shardingConnectionHook的引用，而shardingConnectionHook则是对shard链接hook的具体实现，如下：

    //server.cpp
    class ShardingConnectionHook : public DBConnectionHook {
    public:

        virtual void onHandedOut( DBClientBase * conn ) {
            ClientInfo::get()->addShard( conn->getServerAddress() );
        }
    } shardingConnectionHook;

   当然这里不是对addShard及相应command命令进行分析的时候，因为mongodb有一个架构设计非常清晰的指令(command)体系，有关该方面内容我也会专门接时间来加以说明。

   还是回到程序主流程上，在onHandedOut处理完之后，就可以将获取到的链接实例返回了。但如果没有可能的链接信息，那么就要创建一个链接（cs.connect( errmsg )）并将其入库，如下：

    //connpool.cpp
    DBClientBase* DBConnectionPool::_finishCreate( const string& host , DBClientBase* conn ) {
        {
            scoped_lock L(_mutex);
            //获取池中相应host的PoolForHost信息并将创建的链接数（_created属性）加1
            PoolForHost& p = _pools[host];
            p.createdOne( conn );
        }
        //调用绑定到当前pool的DBConnectionHook中的create方法（施加额外操作）
        onCreate( conn );
        //调用绑定到当前pool的DBConnectionHook中的onHandedOut方法（施加额外操作）
        onHandedOut( conn );

        return conn;
    }

在完成了这一步，链接池的就会多一个connect对象，并使用该对象来链接configServer. 而当balancer执行并相应均衡chunk操作后，会执行如下代码：

conn.done();//将conn放到链接池中(为其它后续操作使用)

下面就是done()函数代码：

    //connpool.h  ScopedDbConnection类
    void done() {
            if ( ! _conn )//如无效则返回
                return;

            /* we could do this, but instead of assume one is using autoreconnect mode on the connection
            if ( _conn->isFailed() )
                kill();
            else
            */
            pool.release(_host, _conn);//如有效则进行池化（添加到链接池）
            _conn = 0;
        }

    //connpool.h  DBConnectionPool类
    void release(const string& host, DBClientBase *c) {
            if ( c->isFailed() ) {//如链接出现异常（比如无法链到服务器），则释放
                delete c;
                return;
            }
            scoped_lock L(_mutex);
            _pools[host].done(c);//否则将其压入链接池供其它操作使用
    }

    //connpool.h  PoolForHost类
    void PoolForHost::done( DBClientBase * c ) {
        _pool.push(c);
    }

   好了，今天的内容就先到这里了。按照惯例，最后用一张时序图来对今天的流程做一下回顾。

   原文链接:http://www.cnblogs.com/daizhj/archive/2011/06/07/mongos_connpool_source_code.html
    作者: daizhj, 代震军
    微博: http://t.sina.com.cn/daizhj
    Tags: mongodb,c++,connpoll,connection,source code

本文链接

Mongodb源码分析--Mongos之分布式锁

2011-05-30T01:52:00Z

     在之前的一篇文章中，介绍了balancer会声明使用分布式锁来协调分布式环境下的信息沟通并确保事务一致性，有关分布式锁的一些原理性信息可以参见这几篇文章：
     http://wenku.baidu.com/view/19ce3085b9d528ea81c77982.html
     http://wenku.baidu.com/view/d94ac11ffc4ffe473368ab27.html

http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95

http://en.wikipedia.org/wiki/Paxos_%28computer_science%29

下图是mongod使用sharding机制时的一个系统架构图（有关如果配置sharding并进行数据存储参见我的这篇文章）：

这里Mongod实现的比较简单，它主要是通过在config服务器结点上创建并维护两个lock集合(lockpings和lock)，并mongos启动时会在这两个集合中各创建一条数据记录，然后通过维护该记录的状态（包括时间戳，state）来标识当前mongos结点的锁使用情况。如果多台机器之间想使用一个锁，只要确保锁的名称一致就行，这里就会在configsvr结点的相应集合中共享这一条记录以确保只有一个mongos结点获得了该锁。

首先mongod会在配置为configsvr结点上创建并维护两个集合，如下图:

config.lockpings:
      _id: 存储mongos发送来的balancer的标识信息（格式=> "机器名称:时间戳:随机数"）
      ping: 以及发送ping指令时的时间（日期时间格式）

config.lock：
      _id: 存储锁的名称（如balancer）
      process: 关联config.lockpings中_id的字段(并与其保持一致)
      state: 锁状态（是否有操作使用该锁）。0为未锁定，1为锁定。
     ts: 锁转为使用状态时的时间戳
     when :锁转为使用状态时的时间（日期时间格式）
      who: 谁使用了该锁(格式为process + 线程名称 + 随时数)
      why: 使用锁的原因（如:doing balancer round）

了解上面内容之后，我们看一下mongos分布式锁的类关系图：

     其中DistributedLock类就是分布式锁的结构，它包括如下信息：
    _name:锁名称，与config.lock中的_id相绑定
    _conn:要链接到的mongod服务器地址
    _ns: 使用的锁集合名称，构造函数将其初始化为"config.locks"
    _takeoverMinutes: 强制接管的时间（当某个lock长时间不被解锁或无响应信息时），这时系统会回收该lock(通过将state置1)
    lock_entry() : 当系统开始获取lock时所执行的操作
    unlock():解除锁定

dist_lock_try类主要用于对上面的DistributedLock类操作进行封装，以便于使用.
其构造函数和析构函数与DistributedLock类的lock_entry()和unlock()方法对应。

下面我们就通过源码来进一步分析其底层的实现原理, 首先我们看一下DistributedLock的构造函数：

//distlock.cpp
DistributedLock::DistributedLock( const ConnectionString& conn , const string& name , unsigned takeoverMinutes )
        : _conn(conn),_name(name),_takeoverMinutes(takeoverMinutes) {
        _id = BSON( "_id" << name /*balancer*/);
        _ns = "config.locks";
    //清理"config.lockpings"集合中旧的（不再持有lock）entry信息,同时构造该集合索引
        distLockPinger.got( conn );
    }

上面的构造方法主要是完成初始化conn,name,takeoverMinutes等相关属性，之后它会调用 distLockPinger.got()来向mongod发送ping指令，如下：

//distlock.cpp
class DistributedLockPinger {
    public:
        DistributedLockPinger()
            : _mutex( "DistributedLockPinger" ) {
        }

        void got( const ConnectionString& conn ) {
            string s = conn.toString();
            scoped_lock lk( _mutex );
            if ( _seen.count( s ) > 0 )
                return;
   //线程方式执行distLockPingThread()方法
            boost::thread t( boost::bind( &distLockPingThread , conn ) );
            _seen.insert( s );
        }

        set<string> _seen;
        mongo::mutex _mutex;

    } distLockPinger;

它使用线程方式来执行distLockPingThread()方法来发送ping指令，并最终执行下面方法：

//distlock.cpp
void _distLockPingThread( ConnectionString addr ) {
     //设置当前线程名称
        setThreadName( "LockPinger" );

        log() << "creating dist lock ping thread for: " << addr << endl;

        static int loops = 0;
        while( ! inShutdown() ) {
      //"机器名称:时间戳:随机数"的process标识
            string process = getDistLockProcess();
            log(4) << "dist_lock about to ping for: " << process << endl;

            try {
                ScopedDbConnection conn( addr );

                // refresh the entry corresponding to this process in the lockpings collection
                conn->update( lockPingNS ,
                              BSON( "_id" << process ) ,
                              BSON( "$set" << BSON( "ping" << DATENOW ) ) ,
                              true );
                string err = conn->getLastError();
                if ( ! err.empty() ) {
                    warning() << "dist_lock process: " << process << " pinging: " << addr << " failed: "
                              << err << endl;
                    conn.done();
                    sleepsecs(30);
                    continue;
                }


                // (主要用于当一个process卸载且没有新实例接着使用该entries时）
                // replace it for a quite a while)
                // if the lock is taken, the take-over mechanism should handle the situation
                auto_ptr<DBClientCursor> c = conn->query( locksNS , BSONObj() );
                vector<string> pids;
                while ( c->more() ) {
                    BSONObj lock = c->next();
                    if ( ! lock["process"].eoo() ) {
                       //找出process信息
                        pids.push_back( lock["process"].valuestrsafe() );
                    }
                }

                Date_t fourDays = jsTime() - ( 4 * 86400 * 1000 ); // 4 days
                //移除超过4天的且非当前process的entries记录
                conn->remove( lockPingNS , BSON( "_id" << BSON( "$nin" << pids ) << "ping" << LT << fourDays ) );
                err = conn->getLastError();
                if ( ! err.empty() ) {
                    warning() << "dist_lock cleanup request from process: " << process << " to: " << addr
                              << " failed: " << err << endl;
                    conn.done();
                    sleepsecs(30);
                    continue;
                }

                // 构造索引，让remove执行更快
                if ( loops++ == 0 ) {
                    conn->ensureIndex( lockPingNS , BSON( "ping" << 1 ) );
                }

                conn.done();
            }
            catch ( std::exception& e ) {
                warning() << "dist_lock exception during ping: " << e.what() << endl;
            }

            log( loops % 10 == 0 ? 0 : 1) << "dist_lock pinged successfully for: " << process << endl;
            sleepsecs(30);
        }
    }

上面的方法首先会更新config.lockpings集合中ping的时间信息，之后从config.lock集合中找出还在持有lock的process信息，并从lockpings集合中去掉除process之外的且时间超过4天的lockping信息。最后为lockpings创建索引，来为后面的更新操作提升效率（该集合中的数据会越来越多）。

我们可以将上面方法简单的理解为在获取使用lock之前的准备和维护工作。

到目前DistributedLock的初始化工作就完成了，下面看一下它的使用流程。在之前的文章中介绍过，当构造分布式锁之后，它会使用下面代码来尝试获取相应的锁：

//mongos项目balance.cpp文件
    void Balancer::run() {
       ......
    DistributedLock balanceLock( config , "balancer" );
    .....
    dist_lock_try lk( &balanceLock , "doing balance round" );
    ......
}

上面的dist_lock_try()就是开始尝试获取当使用该锁（balanceLock）的代码，其构造函数如下：

//dist_lock.cpp
dist_lock_try( DistributedLock * lock , string why )
            : _lock(lock) {
            _got = _lock->lock_try( why , &_other );
    }

它会持有传入的DistributedLock实例指针绑定到其自己的_lock（DistributedLock）属性上，然后使用该_lock来执行DistributedLock的lock_try()方法，这里持有该_lock的主要目的还包括在其析构函数中调用该_lock的unlock()方法，如下：

//dist_lock.cpp
~dist_lock_try() {
            if ( _got ) {
                _lock->unlock();
            }
   }

下面我们分别来看一下lock_try()和unlock()方法：

//distlockk.cpp
bool DistributedLock::lock_try( string why , BSONObj * other ) {
        // write to dummy if 'other' is null
        BSONObj dummyOther;
        if ( other == NULL )
            other = &dummyOther;

        ScopedDbConnection conn( _conn );
  //如果要更新当前lock信息时，用于构造查询条件
        BSONObjBuilder queryBuilder;
        queryBuilder.appendElements( _id );
        queryBuilder.append( "state" , 0 );

        {
            // make sure its there so we can use simple update logic below
            // 在"config.locks"集合中查找"balancer"对象
            BSONObj o = conn->findOne( _ns , _id ).getOwned();
            // 如不存在则添加
            if ( o.isEmpty() ) {
                try {
                    log(4) << "dist_lock inserting initial doc in " << _ns << " for lock " << _name << endl;
                    //添加相应lock信息，注：其余如ts信息会在后面以update方式进行绑定
     conn->insert( _ns , BSON( "_id" << _name << "state" << 0 << "who" << "" ) );
                }
                catch ( UserException& e ) {
                    log() << "dist_lock could not insert initial doc: " << e << endl;
                }
            }
            //当前entry为有效状态时则强制接管（让其过期state=0）
            else if ( o["state"].numberInt() > 0 ) {

                BSONObj lastPing = conn->findOne( lockPingNS , o["process"].wrap( "_id" ) );
                if ( lastPing.isEmpty() ) {
                    // if a lock is taken but there's no ping for it, we're in an inconsistent situation
                    // if the lock holder (mongos or d)  does not exist anymore, the lock could safely be removed
                    // but we'd require analysis of the situation before a manual intervention
                    error() << "config.locks: " << _name << " lock is taken by old process? "
                            << "remove the following lock if the process is not active anymore: " << o << endl;
                    *other = o;
                    conn.done();
                    return false;
                }

                unsigned long long now = jsTime();
                unsigned long long pingTime = lastPing["ping"].Date();
                //config服务器与本机时间产生偏移时则无法获取锁
                if ( now < pingTime ) {
                    // clock skew
                    warning() << "dist_lock has detected clock skew of " << ( pingTime - now ) << "ms" << endl;
                    *other = o;
                    conn.done();
                    return false;
                }
                //计算从ping开始到现在所用时间
                unsigned long long elapsed = now - pingTime;
                elapsed = elapsed / ( 1000 * 60 ); // convert to minutes
                //边界值判断，如大于100年
                if ( elapsed > ( 60 * 24 * 365 * 100 ) /* 100 years */ ) {
                    warning() << "distlock elapsed time seems impossible: " << lastPing << endl;
                }
                //如果lock的elapsed时间未超过强制接管的时间，则false
                if ( elapsed <= _takeoverMinutes ) {
                    log(1) << "dist_lock lock failed because taken by: " << o << " elapsed minutes: " << elapsed << endl;
                    *other = o;
                    conn.done();
                    return false;
                }

                log() << "dist_lock forcefully taking over from: " << o << " elapsed minutes: " << elapsed << endl;
                conn->update( _ns , _id , BSON( "$set" << BSON( "state" << 0 ) ) );
                string err = conn->getLastError();
                if ( ! err.empty() ) {
                    warning() << "dist_lock take over from: " << o << " failed: " << err << endl;
                    *other = o.getOwned();
                    other->getOwned();
                    conn.done();
                    return false;
                }

            }
            else if ( o["ts"].type() ) {
                queryBuilder.append( o["ts"] );//获取当前lock记录的timestamp
            }
        }

        OID ts;
        ts.init();

        bool gotLock = false;
        BSONObj now;
       //lock要更新的详细信息
        BSONObj lockDetails = BSON( "state" << 1 << "who" << getDistLockId() << "process" << getDistLockProcess() <<
                                    "when" << DATENOW << "why" << why << "ts" << ts );
        //将上面信息绑定到$set操作
  BSONObj whatIWant = BSON( "$set" << lockDetails );
        try {
            log(4) << "dist_lock about to aquire lock: " << lockDetails << endl;
            //更新指定条件的lock信息
            conn->update( _ns , queryBuilder.obj() , whatIWant );

            BSONObj o = conn->getLastErrorDetailed();
            //查询指定lock信息（可能是上面刚insert添加）
            now = conn->findOne( _ns , _id );

            if ( o["n"].numberInt() == 0 ) {
             //如出现问题
                *other = now;
                other->getOwned();
                log() << "dist_lock error trying to aquire lock: " << lockDetails << " error: " << o << endl;
                gotLock = false;
            }
            else {
               //成功获取该锁
                gotLock = true;
            }

        }
      //当dist_lock未被恰当的获取传递（即一个事务结束锁后，另一事务获取该锁）
        catch ( UpdateNotTheSame& up ) {
            // this means our update got through on some, but not others
            log(4) << "dist_lock lock did not propagate properly" << endl;

            for ( unsigned i=0; i<up.size(); i++ ) {
                ScopedDbConnection temp( up[i].first );
                BSONObj temp2 = temp->findOne( _ns , _id );
             if ( now.isEmpty() || now["ts"] < temp2["ts"] ) {
                    //获取最新的lock信息
                    now = temp2.getOwned();
                }
                temp.done();
            }
         //如时间戳与本地时间戳一致，表示锁被成功传递
            if ( now["ts"].OID() == ts ) {
                log(4) << "dist_lock completed lock propagation" << endl;
                gotLock = true;
                conn->update( _ns , _id , whatIWant );
            }
            else {
                log() << "dist_lock error trying to complete propagation" << endl;
                gotLock = false;
            }
        }

        conn.done();

        log(2) << "dist_lock lock gotLock: " << gotLock << " now: " << now << endl;

        return gotLock;
    }

上面的方法首先要尝试在config.locks集合中找到相应的锁记录信息，如没有则会创建一条记录。

如有则判断记录的state状态（如果为1表示其正在被使用），如果使用期限未超过强制接管期限（elapsed <= _takeoverMinutes）或未超过100年则，则无法获取当前锁。

当可以修改锁状态时，则使用update去更新lock记录的相关信息（包括state, when,who,why，ts等），同时对异常情况（一个事务结束锁后，另一事务未及时获取该锁）也做了容错处理。

如果上面方法成功执行后，会更新config.locks中的相应数据记录，并返回true，表示当前进程已获取了该lock.

在成功执行锁定的代码段之后，就需要对当前代码段解锁，这是通过下面方法进行的：

   //解除锁定
    void DistributedLock::unlock() {
        const int maxAttempts = 3;
        int attempted = 0;
      //尝试3次解锁
        while ( ++attempted <= maxAttempts ) {

            try {
                ScopedDbConnection conn( _conn );
               //解锁即更新lock信息: state=1
                conn->update( _ns , _id, BSON( "$set" << BSON( "state" << 0 ) ) );
                log(2) << "dist_lock unlock: " << conn->findOne( _ns , _id ) << endl;
                conn.done();

                return;
   }
            catch ( std::exception& e) {
                log( LL_WARNING ) << "dist_lock  " << _name << " failed to contact config server in unlock attempt "
                                  << attempted << ": " << e.what() <<  endl;
                sleepsecs(1 << attempted);
            }
        }

        log( LL_WARNING ) << "dist_lock couldn't consumate unlock request. " << "Lock " << _name
                          << " will be taken over after " <<  _takeoverMinutes << " minutes timeout" << endl;
    }

      mongos会在解锁出现问题（如远程服务器停止响应等）尝试执行三次解锁，解锁主要就是将远程服务器的config.locks中相应锁记录字段state置为0即可。

     好了，今天的内容就先到这里了。

    原文链接:http://www.cnblogs.com/daizhj/archive/2011/05/30/mongodb_source_distlock.html
    作者: daizhj, 代震军
    微博: http://t.sina.com.cn/daizhj
    Tags: mongodb,c++,balance,DistributedLock, 分布式锁

本文链接