《从三到万》是一个马南邨写的一篇文章，被选入过“万恶“的语文课本。上过语文课的，都对这篇文章有过各种解析、剖析，否则怎么才能够考试过关嘛……
不过，我们今儿不谈这篇课文，谈该文中引用的那段文言文，即取自明朝著名教育家刘元卿《应谐录》的那篇，原文题为《奈何姓万》，原文是这么说的：
汝有田舍翁，家资殷盛，而累世不识“之”“乎”。
一岁，聘楚士训其子。楚士始训之搦管临朱。书一画训曰：一字;书二画，训曰：二字;书三画，训曰：三字。
其子辄欣欣然，掷笔归告其父，曰：儿得矣，儿得矣;可无烦先生，重费馆谷也，请谢去。
其父喜，从之，具币谢遗楚士。
逾时，其父拟征召姻友万氏者饮，令子晨起治状，久之不成。父趣之，其子恚曰：“天下姓氏夥矣，奈何姓万!自晨起至今，才完五百画也。”
呜呼!世之学者偶一解，辄自矜有得，殆类是也。
文章写得极其生动有趣呀，不愧是著名的教育家手笔。几百年过去了，我们看到”儿得矣，儿得矣“这么一段话的时候，还能够感觉到这位不知天高地厚的小朋友的狂喜的状态。
事情有时候就是这样，所谓太阳底下没有新鲜事。类似这位小朋友的这种奇怪的推理逻辑，现在还在到处上演。
比如说，市场上有些言论宣称，已经可以用互联网架构完全满足银行核心业务系统的要求，其分布式平台处理能力从数值上来说已经能够完全满足;或者说，其现有架构甚至已经比现有的银行架构要更加先进。
“得矣，得矣!“——真得意呢!
可是，真相是这样的么？
根据笔者与银行专家交流的意见，他认为这种推理是严重错误的，后果非常严重。这么草率的结论，让他觉得非常”捉急“。
读写分离交易与银行金融交易的差别，远隔千山万水
从业务体系上来说，互联网上的交易与银行的金融交易之间，有着非常大的区别，并不能简单地用交易的成交数量来看二者之间的关系。
无论是从业务逻辑、监管方式，还是数据要求上，从业务体系来看，互联网的一些支付方式都与银行业完全不同。这就造就了不同的技术路径。
尽管路径不同，但是其技术原理相同。虽然分布式与集中式是两个对立的模式，但是不同行业的应用特点决定了各自行业的思路。分布式与集中式数据库各有优缺点，也就各有不同的适用环境。
对于互联网行业来说，很多是典型的读多写少的要求，因此为很多开源数据库及其技术提供了条件;但是对于传统密集交易性的行业，尤其是金融业，考虑到单点处理能力以及可靠性、稳定性等问题，采用商用数据的集中式方案更多。
有一些人知道CAP理论，这是在2002年由麻省理工学院的教授在数学上证明了的理论。核心思想就是，在分布式计算(存储)的架构里面，由于网络引起的时延是必然的(Partition Network Toleration)，因此对于一个操作在数据一致性(C=Consistency)和数据可用性(A=Availability)方面必须取舍一个。
简单一点来说，结论就是，分布式计算模式加数据可用的高扩展成为了互联网公司的平台基础，因为，他们能够接受最终的数据弱一致性;而对于金融业来说，则需要数据实时强一致性。
银行业花了二三十年的时间，才逐渐发展起来的各种核心基本架构以及变成原则，来保证数据强一致性，并不是现在的互联网架构能够快速取代的——虽然在外围业务也可以采用分布式架构。
就好像汉字体系发展了数千年，每个汉字都有其来历和规则。虽然，从一、二到三，看起来是非常简单地类推，但是它绝对不是所有汉字的架构原理和来源。
网络调侃可以，但是你可以忍受银行账户的调皮么？
在网络购物的时候，点击付款按钮之后，，经常会出现类似于”暂时无法获取付款结果“这样的提示，有时候这样的意思会被表达的非常的调皮与诙谐，但是意思都是一样的：对不起，您暂时还不知道您的付款是不是成功。
不过，网络购物嘛，大家也就忍受一下，反正过一会儿肯定会好的。那就再去“我的订单“看看状态吧，很可能没找到单子，不可思议？
那就等会儿吧。
过一会儿再去看的话，订单也许就出现了，但是状态可能是”等待付款“。无所谓啦，那就再付一次吧。反正银行账户上面的钱还在。
可是，如果银行系统也是这么调皮，你去查询账户余额，以及进行转账付款的时候，银行总是动不动就说”亲，现在查不到你的余额信息“，”暂时无法取得付款结果“。
会不会抓狂？
所以，那句话怎么说来着？对互联网这种服务的容忍，现在变成了它炫耀的资本。
但是，后面真正在底层进行支撑整个社会金融运营基础的，是银行业，依靠过去30多年间精益求精地系统建设和安全维护。
由于需要承担社会民生稳定不可或缺的金融基本服务，银行金融系统的设计比起电商的交易系统而言要复杂得多。更重要的是，在其业务监管方面要接受银监会、外管局、公安局等多个部门的监管，业务必须要合规。
比如说，某个部门要列出一个黑名单，银行就需要在每个关键点(比如说存取款业务)都要进行检查，更何况这些年中，还要应对各种对于反欺诈、反洗钱等的监管要求。
所以，即便是交易量同等规模，网络交易的复杂度都远远比不上银行系统交易的复杂度。
只是交易量数值相等或者超越，就大喊”得矣，得矣“，真的合适么？
你能忍受动不动银行关门一个月进行对账么？
某互联网数据库的技术文档表明，当主UpdateServer发生故障时，如果不要求强一致性，数据库内部可以自动做主备切换;如果要求强一致性，该数据库内部不做内部切换，等确认数据没有丢失后再强制把某个备UpdateServer设置为主。
很明显，根据这里的技术文档的说明，已经能够发现一致性与数据服务的高可用性产生了冲突。
这对于银行的业务来说就意味着很大的风险。就像之前所说，绝大多数银行的关键业务系统要求强一致性，又要求高可用性。一般来说都建立本地高可用环境，在单点故障时自动切换，保障业务的连续运行。
所以，该互联网数据库的自动主备切换以牺牲一致性为代价不可取。
浅显一点说。
一家大行的核心系统一致性出了问题，即便是几分钟，也可能会影响到上百万的账户账目。问题的关键是，如果是一致性方面出错，管理人员是很难判断业务逻辑的，也就是说不具备程序恢复的可行性。
就像金融专家说的那样，账目错得一塌糊涂，又不知道该怎么恢复，请问这家银行怎么办？
恢复昨天的交易备份，一切重来？那就可能是数亿笔不同渠道交易的重新发起，不现实。也许只能先暂停业务，慢慢搞一个月，再开门。
作为以金融服务为生的银行，可以忍受么？作为银行的用户，可以忍受这样的银行么？
到时候，被误导在核心系统转用其他架构的大行，只能是大呼”奈何姓万“么？
所以，刘元卿说得对呀。
“呜呼!世之学者偶一解，辄自矜有得，殆类是也“。
殆类是也。