有趣的版本号

  计算机的世界,版本号(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函数。

  本文地址:http://www.cnblogs.com/xybaby/p/8403461.html

版本号的形式

  版本号的形式并没有固定的或者约定俗成的格式,完全取决于软件、协议的发布者。

  数字形式(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 }
_PyType_Lookup

 

  代码逻辑并不复杂,分成三步

  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与缓存中的使用。当然,我相信还有更多更有趣的使用场景,而本人所接触的领域比较狭窄,权当抛砖引玉,欢迎各位园友指正与补充。

references

通信协议序列化

服务化体系之-兼容性与版本号

轻松理解MYSQL MVCC 实现机制

前端资源版本控制的那些事儿

MongoDB Sharded Cluster 路由策略

posted @ 2018-02-06 10:46  xybaby  阅读(2660)  评论(2编辑  收藏  举报