非技术人员不知道什么是TPS其实没啥好震惊的，但如果以TPS作为投资公链的重要指标之一，却又不知道什么是TPS，那就真的令人唏嘘了！
TPS，通俗的定义，就是“系统的吞吐量”，专业一点的解释，就是“系统每秒钟能够处理的业务数量”。估计大部分人的理解，也就到此为止了。然而，这是非常表面的理解，对妨忽悠，对求证价值几乎没有意义，甚至还有负面效果！
知道了TPS的定义怎么还会有负面效果，因为“一瓶子不满，半瓶子咣当！”，不求甚解，不如虔诚的无知！
当我们知道了表面的TPS定义后，直觉上会觉得TPS肯定是越大越好喽，这很符合逻辑，然而，事实并非如此！
首先，我必须说，在计算机领域里，TPS其实并不是一个原生概念，何为原生概念？就是底层客观存在的数据指标，比如磁盘转速、网速、CPU赫兹数、进程和线程数等。而TPS其实是一个人造概念，是几种底层数据的一个综合计算结果，是为了在宏观上衡量某些特定系统而制造出来的概念。
以上解释有点虚，我们举个大家耳熟能详的例子，比如比特币。
在比特币这个业务中，TPS的定义可以更加具体的解释为：“比特币网络每秒钟能够处理的交易数！”，然而在这个定义中，真正的原生概念只有“交易数”，而TPS，则是我们人为用一段时间的交易总数除以这段时间的总秒数，而得到的一个指标，代表了平均每秒能处理的交易数，注意是平均，不是真的每秒都在处理交易！
那么问题来了，既然“一段时间”是我们人为截取的，在比特币网络里，我们截取多少呢？一般来说，取最小模块儿，就是一个区块的打包间隔，现在为10分钟左右。注意，第二个原生概念出来了，就是出块儿时间“10分钟”！
OK，如果我们取10分钟为一个标准时间段，然后每个打包块儿里包含4000条交易数据，那么TPS是多少呢？4000 / (10*60) = 6.67，没错这个大概就是比特币网络的TPS，平均每秒6条交易左右，而且每10分钟才处理一次！
到这里，大家可以看到，比特币业务模型中，TPS其实依赖的是三个底层概念：出块时间，每个块儿包含的交易数，以及我们截取的时间段。
一个极端的例子，如果截取1分钟看，我们会发现，十分之九的时间下，比特币网络的TPS是0，因为这段时间并没有出块儿，可如果我们仅仅截取第十个包含了出块时间点的1分钟看，我们的TPS又高达66.67（4000 / 60），这肯定不合理啊！由此可见，我们人为设定的参数的合理性，是依赖于原生参数的，原生参数才是我们真正应该关注的点，人为造出来的参数，是为人服务的，如果人性善，就是一个合理的参数，如果人性恶，这个参数可能就是用来骗人的！
所以，尽管TPS的定义是“每秒”处理的交易数，然而在真实的世界中，无论是比特币还是绝大部分其它区块链网络，都不可能真正的秒级处理业务，除非它每秒钟都在出块儿！
那么问题又来了，既然搞懂了影响比特币网络TPS的原生参数里有“一个块儿包含的交易数”和“出块时间”两个最重要的指标，那么我们为什么不通过增加交易数，或者减少出块儿时间，来提升TPS呢？
先说增加一个块儿里的交易数，影响这个数字的重要指标则又会引出另外一个重要的原生参数，就是“块大小”。比特币中，一个块儿被限制为1M大小，而一条交易数据的大小也是固定的，所以一个块儿里能容纳的交易数上限也就是固定的了。
这里肯定有人会问，把这个块儿大小加大不就完了么？须知增加块儿大小就意味着增加硬盘和带宽的需求，这种问法就像我在公司里做程序架构师的时候，老板说，把系统优化一下啊，然后我直接回答：不用优化啊，直接买更好的服务器，用更好的机房和网络就OK了！你们觉得老板听到我这句话会是什么反应？
一个优秀的程序员，想的应该是在有限的条件下，如何通过算法和架构来优化性能，保障扩展性，而不能把希望一味寄托在硬件的性能和数量上，除非真的没办法了，或者时间真的太赶了！
那么比特币的TPS优化现在真的已经到了实在没办法，或者完全没时间再研究的程度了么？显然并没有！既然增加块儿大小，从程序员角度并不是最佳选择，那么减少出块儿时间可以么？直接整成1秒钟出一个块儿岂不是很爽！？
并不是这么简单，其实区块链的每一个块儿中所包含的数据，并不是仅有交易数据，还都包含格式数据，这些数据一般位于区块数据包的头部，用来做各种标识和安全验证。但如果我们爆块儿过快，很可能造成每个块儿数据都不满，甚至是空块儿，这些块儿的头部数据是一个字节都不少的，这样其实是一种系统浪费，IO压力也会过大。而且爆块儿过快，还会影响“共识机制”，会大大增加共识达成一致的难度，增加系统被攻破的风险性，但是由于这块儿底层我还没有完全研究明白，暂时不展开讲。
既然仅从调节参数难以达到满意的效果，也不想轻易认怂堆硬件，破坏长期的可扩展性，那么作为程序架构师，脑子中就仅剩下一个词了：重构！于是，“闪电网络”应运而生了！关于闪电网络，不是本篇重点，也按下不表。大家只需要知道，这是从底层架构做得大手术，进而大大提升TPS，却又不会带来我前面说得那些调整参数引发的问题，不过任何一个架构都有优缺点，闪电网络也有它的问题，这里不展开。
基于以上科普，我再来看俩个要点：
1，TPS是人为定义的，有弹性的一个参数，其合理性在于所选择原生参数的合理性。比特币的网络相对简单，参数也少。但在一个复杂网络里，比如游戏服务器拓扑结构，一般都会包含：账户服务器、每一个区的服务器群组、跨服的副本或者战场服务器、数据库服务器，WEB服务器等等。这些服务器共同组成了一款游戏的完整系统，这里面涉及的参数就非常多了，任何一个参数都可能影响整个系统的TPS。但在游戏中，我们常常不说TPS这个概念，为什么？因为参数太多了，你说系统TPS提升了，我根本不知道你优化的哪里，甚至都不知道你是什么意思！
所以，我们需要在系统整体TPS上，抽象出各种具体的子系统TPS，并规范出相应的名词。在上面我提到的各种游戏服务器中，大家猜压力最大的是哪一组服务器？是账户服务器，因为账户服务器会面临所有的玩家请求，尤其是在服务器刚重启之后，大量的玩家会瞬时涌入，直接把你的系统堵死挂掉，这时又要继续重启，然后又挂掉，无限死循环！这个时候的TPS，我们称之为“同时登录数”。
为了解决这个问题，我们要怎么办？在玩家非常多的时候，现有硬件是不可能满足无限并发登录数的，于是行业发明了一个做法：“排队登录！”，没错，就是这个曾经让很多玩家蛋疼过的规则！
所谓“排队登录”，就是限制某一时刻，玩家进入服务器的数量，比如每10分钟，只能进4000人？MY GOD！这不就是区块链的出块儿规则么？当然，真实的情况下，游戏的登录TPS要远高于这个数据，刚才的参数举例只是为了让大家容易联想到比特币网络。
而一个游戏系统的整体TPS是个什么概念呢？我们可以认为是“每秒钟支持的在线人数”，这个TPS相对比特币，所受到的影响就太多了，比如刚才说得登录能力，如果玩家连登录都登不进来，TPS就是0！然后还有每一个区的服务器承载力，一般为几千人；数据库IO能力，是个大坑；内存和CPU使用效率，体现程序架构功力的地方，等等。我说这几个还只是比较核心的参数，一个参数没搞好，系统整体TPS就会大幅度下降。
由此可见，目前的商业游戏，为了最大化满足所有玩家的体验，采用了非常复杂的服务器拓扑结构，而区块链相对简单的结构是肯定无法达到目前主流游戏的性能需求的。
那为什么区块链不搞得复杂一点，TPS搞得高一点呢？一方面是区块链共识机制的限制，另外一方面是，复杂常常意味着成本和风险，可以说市面上大部分游戏的服务器是经不起攻击的，大家常常是从游戏规则和法律层面规避这种攻击，让攻击者没有太大的收益，并且要冒着巨大的法律风险。然而区块链的世界里，没有法律保护，还直接跟钱挂钩，我们唯一能依靠的就只有程序，这种极端情况下，简单才是美，简洁才能稳！
2，上面讲游戏服务器拓扑结构的时候，提到会有各种服务器，它们之间常常需要通讯，比如登录服务器验证通过后，需要跟游戏区服务器通讯，给到登录账户信息，然后区服务器根据账户信息去数据库服务器里拉取或者更新一些角色数据。而跨服战斗的时候，副本服务器又需要跟这些玩家所在的区服务器通讯。
上面这一切，我们称之为网络拓扑结构。而这一切，大部分都是在局域网内完成的，大家延时感不大。人眼在40毫秒内，是感觉不到卡顿的，局域网内的通讯时间几乎可以忽略，玩家就算卡，也是服务器网络和玩家家庭网络间的延时造成的。
比较特殊的是跨服战斗，不同区的服务器也许真的不在一个机房，这时候为了让战斗副本保持流畅，我们需要把不同区的玩家数据抓取到一个离大家都比较近的服务器上，保障大家都战斗的比较流畅，等战斗结束，再把战斗结果同步回各自所在区的服务器。
我相信玩过跨服战的朋友们都应该有过等待“撮合”，和等待“玩家进入”的体验，我们甚至会骂那些进的慢的玩家，因为大家都要等他加载进来才能开启战斗。这个体验之所以这么“差”，让人感觉“好慢”，就是因为它不是简单的局域网通讯，是一个点对点或者中央服务器达成的广域网通讯。
人眼可以接受40毫秒的延时，而广域网通讯稍微不靠谱一点就会大于这个延时，而且随着业务复杂和网络拓扑结构的复杂（比如电信和网通的通讯问题），延时甚至会以秒和分钟记，然而即便如此，比起区块链动辄以分钟，甚至是小时记的延时，还算是“丝滑般”的体验了-_-!!
好的，现在我们回到区块链的世界，区块链网络是一个典型的P2P广域网拓扑结构，一个数据包的确认，需要广域网上多方通讯。在这样的网络拓扑结构下，就算真的达到百万TPS，又有什么用呢？就算你运气非常好，确认块儿的几个节点离的非常近，也绝对不可能达到局域网的速度！从肉眼角度，你会看到，DAPP端的上链操作，从发出请求到界面响应，会远远超过40毫秒，所以依然会是“非常非常”卡顿！如果是一般的购买和转账行为，还能勉强用，但如果是及时战斗游戏，那就真的呵呵了。
综上，当我们再看到有项目宣称自己百万TPS的时候，我们应该：
1，看下项目方的原生参数是什么？计算TPS的公式是什么？出块间隔是多少？
2，要知道比特币为代表的POW共识算法是不可能支持很高的TPS的，所以要专门看下项目方是什么共识机制。
3，要知道广域网分布式随机通讯是绝对不可能超过局域网服务器定点通讯效率的，要想满足我们现有APP的丝滑体验，我们需要的不是百万TPS，我们需要的是区块链重构，什么数据上链，什么数据不上链，要精心设计，安全和速度，我们需要取一个折中！丝滑般的体验是TPS、并发量、网络拓扑结构、安全性等综合优化的一个结果！
4，严谨的求证态度下，也不要限制自己的想象力，随着硬件性能逐步提高，量子计算机和5G网络等基础设置的突破，设置是一些没想到的技术突破，也许有一天，区块链的拓扑结构不用怎么重构也能有丝滑般的体验了，互联网时代我们不就真的经历了这个过程么？
为了让您和您身边的朋友不再被项目方百万TPS忽悠，甚至因此而乱投资，请转发本文，谢谢^_^.
相关文章
