老师过年好，祝您新春快乐！ 对于第一个主观题，我是这么思考的。 首先，火车票动态SKU是12306的核心域，应该花很大的成本去改进，就像课程所说，12306也有雄厚的财力可以去解决，但是有啥特殊的硬件，我还不知道。这里就从咱们课程主要涉及的数据处理的视角出发去思考。 其次，购买火车票的过程主要涉及的是交易数据，应该使用关系性数据库处理最核心的交易环节。 最后，火车票售票张数绝对量很大（全国铁路已累计发售车票 1.75 亿张，每天的发售量都在 1000 万张以上），交易并发大（12306 在高峰日平均 1 秒就要承受 170 多万次点击），业务复杂（火车票的种类是动态变化的）。 1、从对数据的操作来看，无非是分成读和写两类。所以，本质还是处理读写、写写两类冲突，额外的特点是火车票是动态变化的，所以库存查询应该不适合使用REDIS之类的缓存，这样，数据库和缓存的同步成本太大了。 2、避免数据读写冲突。对不同数据的操作不会引起冲突——不同的路线不会冲突，所以应把不同的路线车票数据分开存储，这样降低了数据的并发，也减少冲突。相当于做了分库，需要在存储节点前加上带路由功能反向代理。 3、处理数据读写冲突。由于数据并发过大，为了提高处理速度，单节点不应该采用可串行化隔离级别。查询车票余量要尽可能实时，所以不需要可重复读；所以采用读已提交就可以了。同时，由于并发量比较大，也不应该采用乐观协议。 4、不需要分布式事务。一是分布式事务比较慢，影响处理速度；而是将不同路线分布到不同节点，单节点就应该足以应付数据量。 为了提高可靠性，需要考虑多机有容灾的情况，数据存储在多个副本上。为了保证交易结果的准确定，单调读\写，自读自写一致性，先读后写一致性都要满足，所以就是需要满足线性一致性。如果用关系数据库，那所有读写请求都需要发给主节点，高并发下的主从同步还是状态复制机，我的理解，比如MySQL之间同步用的BINLOG就是命令。节点状态的共识依靠分布式共识算法。