今天答题器问题交流群里，有老师反馈了一个问题：有的学生答题器绑定不上。宁哥说可能是别的教室的学生的答题器错误绑定到了该信道上。
这个问题好像出现了很多次了。我想了一下有没有啥解决方式。
首先，我分析了一下流程，
这里涉及到ITS系统，答题器接收端，答题器发射端3个对象，出现的问题就如图所示，别的教室的学生占用了2号信道也就是小明的信道。
我开始的思路是在具体绑定前，加一个确认环节，也就是确认发射器和接收器中的1、2、3的对应关系，绑错了的就解绑然后再绑定。但宁哥说已经绑定过的发射端是有优先绑定权的，别的答题器很难绑上。
我又想了一下，如果多加一些空位呢，别的学生也可以和空位绑定。宁哥说答题器的位置是冗余了，可是学生不冗余啊。
我又仔细分析了一下，其实图中是有两次绑定的，一次是答题器发射端和接收端中1、2、3信道的绑定，第二次是1、2、3信道和小红、小明、小东的绑定，发射端和接收端1、2、3信道的绑定我们没法控制，但是1、2、3信道和小红、小明、小东的绑定我们可以控制啊。
如果在这个环节控制，那么之前的两种方式就都可以了。比如 多一些冗余答题器位置，如果绑错了，就解绑图中信道和学生的对应关系，然后用新的绑定了正确发射端的信道来绑定学生，如图所示：
或者不用管绑错的信道，用冗余的信道来解绑正确的发射器，然后用正确的信道来绑定学生。
总之就是发射端和信道的绑定可以冗余，可以绑错，但我只从其中取正确的来和学生绑定，多余的错误信道不去管。
这样就解决了信道和答题器发射端总是绑错和占用的问题。
整体的思路就是通过冗余来允许信道和发射端的错误的绑定，我们只从中取出正确的信道来和学生绑定。
这就像我们对服务器可用性思路的演进一样，一开始的思路就是请求和具体的服务器绑定，为了保证可用，会买更可靠的服务器，当然也会更贵。
现在的普遍思路是加一个负载均衡层，通过冗余来允许服务器的出错，通过负载均衡层来屏蔽掉该错误，保证总有一个服务器是可用的就行。类似kafka的isr架构。
有人说计算机领域绝大多数问题都可以通过加一个中间层来解决，是有一定道理的。
从学生列表的角度看，信道就是冗余的，就像服务器的冗余一样。我们要做的就是加一个负载均衡层，也就是学生和信道的绑定关系。
网友评论