红绿灯机制触发的思考

一、背景
大约二周前,和往常一样,骑电瓶车驶入珠江路/进香河路交叉口左转待转区等待红绿灯放行,直行黄灯倒计时为0,遂即准备骑出(按照以往经验,直行黄灯倒计为0时,左转交通灯变为绿灯) ,突然发现左转方向的绿灯没有亮,而是亮了红灯,倒计时为5s,当时很诧异,交警怎么修改了交通灯的规则,后续也触发了一系列的思考。
二、思考
1. 红绿灯规则
城市信号灯设计的初衷是让各个方向的行人车辆可以畅通无堵地通行,路面上当且仅当只有一个方向通行,类似于CPU调度执行各个进程。在满足最基本要求,即让各个方向的行人车辆可以畅通无堵地通行前提下,需要考虑的是如何提高通行效率,涉及的问题包括:
1) :如何设查每个方向占用路面通行权的时间

2) :各个万问如何平滑过渡

(1)每个方向占用路面通行权的时间

如果仅从局部出发,即只考虑当前路口交通通行,采用时间轮询算法是最公平的,但是实际上每个方向的车流量是不均匀的,所以需要采用基于车流量大小的加权时间轮询算法,车流量越多,相应地占用路面通行权时间越长,反之则相应地占用路面通行权时间越短,的确,这种方法将问题解决的毫无挑剔!但实际上大家可能平时或多或少会发出如此感慨"靠,什么玩意,刚过一个红绿灯,前面怎么又是红灯,唉,又要迟到了",这种情况下的交通灯设计只保证了局部最优,却忽略了全局最优, 目前只发现中山南路交通灯设计有全局最优解(其它地方可能也存在) ,开车/骑车的人会发现,过一个红绿灯后,前面一路绿灯,畅通无堵, 飞一般的感觉。

(2)各个方向如何平滑过渡

按照各个方向都应该有机会占用路面通行权原则(类似于不能使得某一进程一直无法被CPU调度而饿死) ,执行完路面所有方向为一个周期。实际过程中,发现方向交接期间是最容易出现问题的时候,即方向A释放路面通行权并且方向B占用路面通行权。除了时间上的交接期外,空间上的交界处,一向也是出现问题最多的地方,比如赫赫有名的金三角就属于中缅泰三国都不管的地带,使得毒贩猖獗,不过也使得我们后续有机会看到<<湄公河>>这样的经典国产电影;

如何将方向A释放路面通行权方向B占用路面通行权两个动作完美地衔接起来?

初期只有红绿灯,即未引入黄灯机制时,交通部门忽略了车辆通过路口这个动作的时延性,即这个动作产生影响具有一定的时长。
比如T0时刻方向A绿灯转红灯,方向A驶出最后一辆车1,而与此同时正好是方向B红灯转绿灯时刻,方向B驶出第一辆车2,在T0+t时刻,车辆1和车辆2在路口某处发生碰接,类似于链路上报文发送的碰撞冲突,就是因为方向A绿灯转红灯时刻驶出的最后一辆车对其它方向产生的影响不是即刻消失的,而是会持续时长x,其中X为车辆驶出路口需要的时间。
相应地,设计出黄灯的规则,本质就是时延作用,但是现在的黄灯规则只是警示作用,闯黄灯不会受到惩罚,所以还是会有一部分人闯黄灯,那么最终其实和没有引入黄灯机制情况是一样的,极易引发车辆通行冲突,即发生碰撞,最近一次网易新闻报道镇江汽车离奇碰撞就属于这一种情况,一方闯黄灯通过路口时与另一方向驶出车辆发生碰撞,所以为了自己和家人,千万不能闯黄灯。交警部门在珠江路/进香河路路口引入黄灯后继续亮红灯的新举措就是用来解决上述冲突问题。 
古言说得好,忍一时,风平浪静;退一步,海阔天空,那么在交通灯两个方向衔接处,前后双方都退一步,即产生时延以规避即刻动作影响的时间跨度性;
可以采取的做法有两种：
一种是当前者退一步,提前释放路面通行权;
另一种是后者退一步,延迟占有路面通行权;
(为了考虑效率,不考虑双方都让步这一种做法)

2.技术拓展

存在大量类似上述交通灯机制的技术,即涉及服务衔接的处理,比如备份机制中主发生故障后备接管或者主被更优的主抢占等等;
所具备的特点是:双方提供相同类型的功能服务;
目前主要存在两种角色组合:
一种是前后服务的双方地位平等;
一种是前后服务的双方地位不平等,比如主备机制;
什么时候切换服务?
1. 定时器机制
最简单的方式就是定时器机制,比如红绿灯时间,定时器方式的特点是结果可以预期,并且双方会对切换时刻达成一致;
2.切换感知
还有一种方式不可预期性,比如主备机制,因为不知道主到底什么时候发生故障,所以也就只能靠双方感知触发切换,无法依靠定时器机制来实现; 
注:网络设备都是基于分布式处理,如果采用的是集中式管理,比如SDN技术,就能够保证双方感知一致性,效果会和定时器机制一样,此外主备路由的切换,也属于这种情况,由于主备都在一个设备实体上,所以主备对切换时机感知一致。

那么该如何感知?

目前网络都是依靠协议报文进行交互,所以相应地也基本都是依靠报文检测来感知,比如心跳HELLO报文检测等等,具体问题的备份技术可能采取的方法不一样,这里就不展开论述了。

如果双方依赖于感知切换时机机制的话,必然存在下面三种情况,其中A是当前服务提供者, B是接替者:
情况一: A先感知,中止职责,停止服务, B滞后感知;
情况二: AB同时感知, A中止职责,停止服务, B行使职责,提供服务;
情况三: B先感知, A之后感知;
(1) A先感知,B后感知
这种情况,存在一段无人行使职责的真空期,在此期间,消费者不能接受服务。
那么怎么规避这个问题呢?在前述红绿灯案例分析中,我们得知处理的措施有两种:
A作出让步;
B做出让步;
由于B还未感知到切换,所以只能采用A作出让步这一措施,当A感知自己不再需要行使职责时,不是立刻停止服务,而是继续延时服务一段时间。一段时间到底为多少时长?可以人为设置时长,一般会有经验参数值,这种方法由于实现简单,所以被高频率使用;但是在某些特殊情况下人为设置时长值可能
会存在问题,比如一段时间后B继续掉链子未衔接上提供服务怎么办?最好的做法是A继续提供服务直到B开始提供服务(这里成立的一个假设前提是AB同时提供服务不
会对用户产生影响,比如用户面对两种服务会产生混乱,不知道该用服务A还是服务B)
(2) AB同时感知
AB能够同时感知切换时机是最理想情况,但是需要考虑类似红绿灯可能出现的问题,即A最后一次服务产生的影响是否具有时间跨度性,会不会对B提供的服务产生影响?
如果存在时间跨度性,则需要考虑引入时延机制,可以采用珠江路新采用的红绿灯规则技术;
(3) B先感知, A滞后感知
这种情况下,存在AB同时提供服务重叠期。
如果AB同时提供服务会对用户产生影响,那么采用B做出让步这一措施,也就是当B感知需要切换时,不是立刻提供服务而是延迟一段时间再提供服务;

如果AB同时提供服务不会对用户产生影响,则可以不考虑额外处理;

3.小结

如何保证前后服务能够平滑过渡,最大程度地保证服务质量，需要考虑下面两个问题:

(1)服务事件产生的影响是否具有时间跨度；(车辆穿过路口,报文发送至目的端都是需要一定时间的) 
(2)前后服务对服务交接时刻认识是否一致; (需要考虑提供服务的载体是否在同一个实体,还是在不同实体?不同实体情况下,如何感知切换信息等)
世上存在的问题其实是有限的,只不过是不同的表现方式而已,所以平常需要仅仅抓住问题的本质,掌握一类问题的通用解法,可以解决一大串问题,包括协议其实就是生活在网络关系组织中的写照。