业务中如何考虑座位问题

在查看节目座位时，如果节目可以选择座位的话，在节目详情页面会有可选座的说明

可以点击选座购买，接着会跳转到选择座位的页面

关于座位的数据存放问题要结合缓存和数据库的设计一起来考虑，在数据库中座位肯定是要跟演唱会相关联的，也就是多对一的关系 而在缓存中的设计思路同样也是将如此，具体的设计可以用下图来表示：

也就是缓存中的key是演唱会，value对应的是此演唱会下的座位列表

数据结构问题

我们想如果使用key-value这种最简单的结构是否适用？首先从业务方面入手，我们在查询演唱会时，如果可以选座的话，是可以看到所有的座位的，这时需要从缓存中查询， 如果要订票的话，也要查询座位，用户购票后，也要去查询具体的座位信息，如果是key-value结构，那么要想查询具体座位，就需要在这个演唱会下来循环座位列表， 根据座位id来命中找到对应的座位信息，这种查询效率太过低下，所以key-value结构肯定是不能使用，

存储的粒度问题

除了上述查询效率的问题外，还存在另一种问题，我们就比如说某个演唱会，演唱会馆规模一般，可以容纳1万名观众，

当用户查询节目的座位时，就需要查询这个演唱会下的1万个座位，如果用户想真正的订票了，就需要在这1万个座位中来修改座位的状态信息，如果并发量一高，这种操作 就会随着并发量越来越高而变得越来越频繁，那么每次都要操作这1万个座位，对于项目中的内存压力和网络压力都是不小的挑战

匹配座位问题

用户能否手动选择座位是根据节目或者演唱会的规则来指定的，如果手动选座用户直接选择想要的座位就行了，如果这时别的用户已经购票完了，那么提示用户已经被购买即可

但如果是自动匹配座位，我们就需要多个人的座位排列问题：

一般购票时如果选择多个购票人的话都是想尽量坐在一起，比如说一次买了两张票，那么这两人是要尽可能挨在一起的，如果某一排没有两个相邻的座位了，那么就要到下一排去找到两个相邻的位置

分配流程(以两个人为例)

• 要在相同的座位档次中进行匹配
• 从所属票档的第一排中查找是否有相邻的两个位置
• 如果没有则依次从第一排找到最后一排
• 如果没有存在相邻的两个位置，但存在前一排和后一排的列相同，那么也匹配出来
• 如果都没有匹配到，那么就只能随机查找两个位置
• 如果没有找到有位置，或者找到的位置不够两个，那么就抛出异常，不继续执行

分配座位流程图