Simone地铁刷卡机系统是如何工作的？如何应付分布式大容量的刷卡任务？
的有关信息介绍如下：
谢邀，不过不是内部人士，从一个后端码农的角度分析下这个问题吧
首先，北京地铁和公交公司刷卡都使用的一卡通公司制的一卡通（地铁也有单程NFC票），从漏刷卡时的情况看，刷卡消费的记录是存在卡上的，并且地铁、分段计价的公交车和单一票制的公交车的计费彼此独立。根据我的观察，这个应该是一个基于NFC卡的电子钱包应用——也就是说，计费工作极有可能是在AFC闸机处，根据NFC票卡上的信息，本地计算的，并不是一个高并发的交易系统。
但是，作为一个健康系统，必须假定任何外部数据都可能是伪造的，因此，必须有发现恶意用户的能力，这需要记录所有交易信息，进行后台核算，判断出恶意用户，加入黑名单，这个统计功能的实时性越好，系统的抗风险能力就越强。
此外，为了方便地铁和公交公司统计客流、收入情况，方便公共安全部门的工作，以及为了某些抽奖之类的用户信息收集工作的需要，刷卡也是需要被记录下来到。
好了，虽然我认为这个系统不是一个并发交易系统，但仍然需要从分部在全市范围的固定与刷卡机、充值平台上，近实时地收集数据的能力。下面我们来分析一下这个系统的需求。
------- >8 --------- 分布式采集系统设计的分隔线 --------- >8 -------
首先，北京地铁公司和京港地铁公司每天都会公布前一天的客流数据的，比如
上面是昨天的北京地铁和京港地铁的客流统计，两者的统计方法实际不太一样，直接相加是不太科学地，不过我们估算的时候考虑数量级就可以了，相加不无不可，北京+京港地铁的单日客流峰值是1000万出头（不是昨天了哈）。忽略单程票用户，并认为所有用户都集中在4个小时的峰值时间内，每人进出刷卡两次，那么，每秒的刷卡量是
做后端系统的同学大概都知道，这个并发量其实实在算不上大，对比一下，支付宝双十一的交易量是1.88亿笔，当天第二分钟就有79万笔（来源：
），这个数字是北京地铁刷卡峰值的10倍左右，而且还是一致性要求更高的支付交易。
对于每秒几千次的分布式日志收集系统，实际不需要太多的技术含量，用一个消息队列系统或类似系统收集，然后装载到数据库或其他结构化/非结构化存储系统就可以，规划的时候，需要更多考虑的是存储容量，而不是并发压力，同时要考虑存储的结构有利于做查询和数据挖掘应用。如果是个多节点的分布式系统，支持各种查询、批量计算应用的应该是富富有余的。
以上所有推断都依据公共发布的数据，嗯，外部人士无责任推断，仅供参考
------- >8 --------- 补充信息的分隔线 --------- >8 -------
补充一个热乎的，今天（12月10日）的新闻：
实际地铁AFC系统的挑战很大程度在机械-电子设备配合，工作可靠性上，收集数据的压力只是一小部分，呵呵
