有趣的版本号
计算机的世界，版本号(version)无处不在，不管是发布的软件、产品，还是协议、框架。那什么是版本号呢
在这里是这样定义的：
Software versioning is a way to categorize the unique states of computer software as it is developed and released.
软件版本号是对开发、发布中的软件的状态的唯一（unique）概括。简单来说，协议就是对一组状态的手工签名。作为程序员，我们经常用md5来签名，保证数据完整性、可靠性。但是我们很难说，对软件或者协议计算MD5，那么版本号就是手工维护的签名。
为什么需要版本号，是因为软件（如linux内核）、协议（如http）都是在不断的发展完善中，也许是修复上一个版本的bug，也许是引入新的特性。当然，不能说有了新的版本就立马抛弃旧的版本，用户（广义的，程序员也是用户）是不会答应的，新版本也许有更高级的功能，但我用不到；新版本也许性能更好，但是不一定稳定。而且，版本升级是一个复杂的事情，维护老系统的程序员早都离职了，谁敢去升级。还有，开源的、免费的产品一旦放出，就不再属于开发者了。因此，多个版本的软件、协议并存是必然的事情，比如在对于Python语言，不管是官方还是一些开源组织，都呼吁放弃Python2，转向python3，但python2还是活得好好的。只要有多个版本 -- 本质是多组不同状态的软件 -- 存在，我们就需要用版本号予以区分。
软件、协议中的版本号，其最大的作用在于避免鸡同鸭讲。当我们讨论问题的时候，首先得明确大家是在相同的语义环境下，其中，版本号就是一个很重要的context，因为同一个术语在不同的版本可能代表的意思完全不一样，比如Python中的range函数。
版本号的形式
版本号的形式并没有固定的或者约定俗成的格式，完全取决于软件、协议的发布者。
数字形式(numerically)的版本号是最为常见的，比如http1.1，iPhone6， python2.7.3，其中 x.y.z 这种格式又是最为常见的。a代表大版本(major version)，不同的a也许是不兼容的；b代表小版本(minor version)，同一个大版本中的小版本一般是兼容的，小版本一般新增功能；c一般是修bug(revision)。
在服务化体系之－兼容性与版本号一文中，作者介绍到，在微服务结构中，服务的升级是高频度的事情，但服务升级的时候，一些接口是兼容的，而另外一些接口而是不兼容的。客户端不可能与服务端同步升级，因此多个版本的服务并存也是常态。那么在存在多个版本的服务时，客户端请求如何路由，就依赖于版本号：
服务的版本号，和软件的版本号一样，一般整成三位：
第一位：不兼容的大版本， 如1.0 vs 2.0
第二位：兼容的新功能版本，如1.1 vs 1.2
第三位：兼容的BugFix版本，如1.1.0 vs 1.1.1
果拿着低版本的SDK(如1.0.0) 发起请求，会被服务化框架路由到所有的兼容版本上（如1.1.1，1.2.0），但不会到不兼容的版本上的（如2.0.1）。
当我们使用一个软件、协议的时候，了解其版本号规则也是有好处的，比如Linux内核，也是x.y.z的形式，如2.6.8，但是第二位y却有特殊的意义：偶数表示稳定版本；奇数表示测试版本.
通信协议中的版本号
上面提到了兼容性，兼容性也是一个很广泛的词汇，在本文中，专指不同版本的软件、协议能协同工作，这个在通信协议、网络接口中非常广泛。在《通信协议序列化》一文中，作者循序渐进，从最简单的紧凑模式过渡到类似protobuf这种高级模式，在这个过程中，就提到了兼容性。本节内容都是对原文的引用。
在最简单的版本中，协议架构是这样的：
1 struct userbase 2 { 3 unsigned short cmd;//1-get, 2-set, 定义一个short，为了扩展更多命令(理想那么丰满) 4 unsigned char gender; //1 – man , 2-woman, 3 - ?? 5 char name[8]; //当然这里可以定义为 string name；或len + value 组合，为了叙述方便，就使用简单定长数据 6 }
种编码方式，称之为紧凑模式，意思是除了数据本身外，没有一点额外冗余信息，可以看成是Raw Data。虽然可读性差，但是节省内存和带宽。
但是当需要扩展协议内容的时候，问题就来了。比如，A在基本资料里面加一个生日字段，然后告诉B：
1 struct userbase 2 { 3 unsigned short cmd; 4 unsigned char gender; 5 unsigned int birthday; 6 char name[8]; 7 }
这是B就犯愁了，收到A的数据包，不知道第3个字段到底是旧协议中的name字段，还是新协议中birthday。
这是一个兼容性与可扩展性的问题，而引入版本号，加一个version字段就能解决这个问题
1 struct userbase 2 { 3 unsigned short version; 4 unsigned short cmd; 5 unsigned char gender; 6 unsigned int birthday; 7 char name[8]; 8 }
不管以后协议如何演变，只要version字段不同，接收方就能够正确解析协议。
MVCC
Multi-Version Concurrency Control 多版本并发控制
MVCC是一种并发控制（ concurrency control ）机制，在RDBMS中有广泛应用。并发控制解决的是数据库事务acid中的I（Isolation，隔离性），比如一个读操作与一个写操作并发执行，如何保证读操作不读取到写操作未提交的数据，即避免脏读（dirty read）。
要实现隔离性，最简单的方法是加锁（Lock-Based Concurrency Control），即一条数据记录同时只允许一个事务操作，比如并发读写的话可以使用读写锁。加锁虽然能解决并发控制的问题，但是在长事务中也会出现锁的争用甚至是死锁的情况。而MVCC通过为每一个数据项保存多分拷贝，每一个事务操作的其实是数据在某一时间点的一份快照，除非事务被最终提交，那么其他事务是无法读取到中间状态的，这就达到了隔离性的要求。
加锁与MVCC经常配合使用，二者在理念上有明确的区别，加锁是悲观的，认为很大概率会冲突，所以使用这一行数据之前先加锁，在解锁之前其他人都不能使用这条记录；而MVCC是乐观的，认为冲突的概率较小，所以使用时先不加锁，如果提交的后面发现冲突了，再自行回滚。
对于一个实现了MVCC的数据存储引擎，以更新一个记录为例，并不是在原来的记录上直接更新，而是拷贝、创建一个更高版本的数据记录，然后在新的版本上更新。这样即使同时有其他事务进行读操作，也是在一个稍微旧一点的版本上读取，互不影响。只有当更新记录的事务提交之后，修改数据库元数据，其他事务才会读取到最新版本的数据记录。
但MVCC对于并发写操作就没有那么好使了，多个并发写在提交的时候很可能会冲突，如果发生冲突，就需要回滚，也可以通过加锁的方式来避免并发写。
网上有很多MVCC在工业界上的实现，比如《轻松理解MYSQL MVCC 实现机制》这篇文章中对innodb mvcc使用详细介绍。
MVCC这种思想在分布式事务中也可以借鉴，在刘杰的《分布式原理介绍》中有相应介绍
缓存中的版本号
咋眼一看，似乎缓存中的版本号与软件、协议的版本号不是一回事，不过一细想，其实都是对一组状态的唯一签名。版本号在缓存中使用非常广泛，其根本作用在于解决缓存过期、不一致的问题。下面给出几个例子
web中的版本号
对于这个，前端开发人员应该都很熟悉，我只是班门弄斧，做个简单介绍。详细的可以参见《前端资源版本控制的那些事儿》
为了优化网页的加载、响应速度，一般会开启浏览器的缓存功能，即浏览器会缓存资源文件（js、css）。比如下面的index.html引用了两个资源文件：
<link rel="stylesheet" href="a.css"></link>
<script src="a.js"></script>在缓存时间内访问页面时，浏览器不会真正发出请求，而是使用缓存的资源文件。
但这样也会引入新的问题，那就是当服务端修改html文件与资源文件，发布之后，客户端会拉取到最新的index.html，但是读取到的资源文件有可能还是旧的 -- 读取到的是浏览器缓存的资源文件。这就暴露了任何缓存最重要的问题，缓存过期的问题，当缓存系统的数据与原数据不一致的时候，就不应当再使用缓存中的数据，而是拉取最新的原数据，同时缓存最新的元数据。
但是在浏览器缓存这个实例中，浏览器是无法及时感知到缓存的数据已过期。虽然设置了过期时间（expire），但这个过期时间只是单方面的，只能约束客户端（浏览器）的行为，服务端并不保证在这个过期时间内不更新内容。这个不禁让我想到lease机制，lease机制保证了在过期时间内不会修改原数据，因此通过缓存读到的数据一定是最新的。
那么如何避免浏览器读取到过时的缓存资源文件呢，最常用，且一般情况下也够用的方法就是加上版本号。
<link rel="stylesheet" href="a.css?v=0.01"></link>
<script src="a.js?v=0.01"></script>
这样当资源文件变化时，只需修改版本号（上面的v），浏览器就会去服务器拉取最新的资源文件。当然，如果每次修改资源文件的时候都手动修改这个版本号，也是一个费力切容易出错的工作，所以一般都会引入自动化脚本，发布时自动修改版本号。
MongoDB元数据缓存
关于MongoDB，在我之前的文章也有一些介绍。在这里讨论的是MongoDB中元数据（metadata）的缓存，MongoDB中，元数据主要是每一个chunk包含的数据范围（range），以及chunk与shard的映射关系。元数据是整个系统的核心，需要保证高可用性与强一致性。
如上图所示，是MongoDB最常见的Sharded Cluster结构。其中，config server存储系统的元数据；shards真正存储用户数据；而mongos缓存元数据，利用元数据指定最佳的执行计划，也就是路由功能。可以看到，应用（Client app）直接与mongos交互，实际的线上应用，一般也是mongos与应用程序部署在一起，config server 与 shards对用户是透明的。
既然应用程序利用mongos上缓存的元数据进行路由，那么缓存的元数据就必须是准确的，与config server强一致的，否则用户请求就可能被路由到错误的shard上。那么MongoDB是如何解决的呢，答案就在MongoDB Sharded Cluster 路由策略
简而言之，就是增加版本号，元数据的每一次变更（chunk的分裂与迁移）都会增加版本号。这个版本号，在shard本地和元数据中都会维护，自然mongos缓存的元数据中也是有版本号的。当请求被mongos路由到某一个shard时，会携带mongos上的版本号，如果该版本号低于shard上的版本号，那么说明mongos上缓存的数据已经过期，需要重新从config server上拉取。
Python method cache
在《python属性查找》中，介绍了属性查找的顺序，而method属于类属性，如果一个method在类中没有找到，那么会按照mro的顺序在基类查找。那么，对于在一个多层继承的类体系中，属性访问是不是会很慢呢，理论上确实如此，但是实践测试的话并不会很明显。原因就在于在python2.6中，引入了method cache：
Type objects now have a cache of methods that can reduce the work required to find the correct method implementation for a particular class; once cached, the interpreter doesn’t need to traverse base classes to figure out the right method to call.
可见，python解释器会缓存访问过的method，这样就避免了每次访问的时候遍历基类。
但是，Python是动态语言，可以运行时改变代码的行为，也就包括增删method，这个时候缓存就与原始数据不一致了，Python是这么解决的
The cache is cleared if a base class or the class itself is modified, so the cache should remain correct even in the face of Python’s dynamic nature.
在源码（2.7.3）中，每一个缓存的entry都是如下的struct
1 struct method_cache_entry { 2 unsigned int version; 3 PyObject *name; /* reference to exactly a str or None */ 4 PyObject *value; /* borrowed */ 5 };
核心的函数_PyType_Lookup如下：
1 PyObject * 2 _PyType_Lookup(PyTypeObject *type, PyObject *name) 3 { 4 Py_ssize_t i, n; 5 PyObject *mro, *res, *base, *dict; 6 unsigned int h; 7 8 if (MCACHE_CACHEABLE_NAME(name) && 9 PyType_HasFeature(type, Py_TPFLAGS_VALID_VERSION_TAG)) { 10 /* fast path */ 11 h = MCACHE_HASH_METHOD(type, name); 12 if (method_cache[h].version == type->tp_version_tag && 13 method_cache[h].name == name) 14 return method_cache[h].value; 15 } 16 17 /* Look in tp_dict of types in MRO */ 18 mro = type->tp_mro; 19 20 /* If mro is NULL, the type is either not yet initialized 21 by PyType_Ready(), or already cleared by type_clear(). 22 Either way the safest thing to do is to return NULL. */ 23 if (mro == NULL) 24 return NULL; 25 26 res = NULL; 27 assert(PyTuple_Check(mro)); 28 n = PyTuple_GET_SIZE(mro); 29 for (i = 0; i < n; i++) { 30 base = PyTuple_GET_ITEM(mro, i); 31 if (PyClass_Check(base)) 32 dict = ((PyClassObject *)base)->cl_dict; 33 else { 34 assert(PyType_Check(base)); 35 dict = ((PyTypeObject *)base)->tp_dict; 36 } 37 assert(dict && PyDict_Check(dict)); 38 res = PyDict_GetItem(dict, name); 39 if (res != NULL) 40 break; 41 } 42 43 if (MCACHE_CACHEABLE_NAME(name) && assign_version_tag(type)) { 44 h = MCACHE_HASH_METHOD(type, name); 45 method_cache[h].version = type->tp_version_tag; 46 method_cache[h].value = res; /* borrowed */ 47 Py_INCREF(name); 48 Py_DECREF(method_cache[h].name); 49 method_cache[h].name = name; 50 } 51 return res; 52 }
代码逻辑并不复杂，分成三步
step1: 如果该函数有缓存，且缓存版本号与类型当前版本号一致（method_cache[h].version == type->tp_version_tag），那么直接返回缓存的结果；否则
step2：通过mro，找出method name对用的method实例
step3：缓存该method实例，版本号设置为类型当前版本号（method_cache[h].version = type->tp_version_tag）
从上面的几个例子可以看出，缓存中的版本号有时也是dirty flag或者lazy 思想的运用：当缓存内容过期的时候，并不是立即清空或者重新加载新的数据，而是等到重新访问缓存的时候再比较版本号，如果不一致再拉取最新数据。
总结
本文并没有一个明确的主题，都是我平时发现的版本号（version）在各种场景下的使用，比较有趣的是MVCC与缓存中的使用。当然，我相信还有更多更有趣的使用场景，而本人所接触的领域比较狭窄，权当抛砖引玉，欢迎各位朋友们指正与补充。