| 知乎专栏 ｜ 多维度架构 |
区块链目前的底层只适合做，低频高价值的业务。
区块链的读取性能通常是没有问题的，但是区块链的写入实际上无论你用多少个服务器节点都不能提升，因为写入区块需要做共识算法，这步操作，会在所有节点上进行，同时还需要加密运算，这些操作都是 CPU 密集型操作。所以写入操作是存在瓶颈的。
解决这个问题，我想出了几种方案：
性能解决方案
通过消息队列技术异步写入，将需要写入的区块放入队列，异步完成上链操作。
并行写入，我们可以建设多个区块链平台。多个平台同时服务于业务。
为了达到去中心化并行写入，我们将在客户端通过算法，匹配服务器。而不是在两个平台前面增加负载均衡。因为这样又回到了中心化系统。
朔源的颗粒度问题，例如“红酒”的溯源，我们是将单位溯源做到箱呢？还是打，或是瓶呢？
我们用“四象限法则”分析
高价值
o |
| o
|
低频率 --------------+------------- 高频率 操作频率
|
o | o
|
低价值
物品价值
通过观察上面图，我们可以看到可以有四种情况，低频低价值，低频高价值，高频高价值，高频低价值
我认为对于低频高价值和高频高价值的业务，尽量做到最小颗粒度。
而对于低频低价值和高频低价值的业务，可以颗粒度更粗。
回归技术本质，我认为区块链技术本身是一种追求分布一致性的数据库。
我们学过数据库的，都知道CAP理论。CAP理论是指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。大多数区块链，放弃了一些可用性，偏向了一致性和分区容错。
区块链并非能解决所有问题，虽然他也算是一种数据库，它能解决问题十分有限，它的数据管理和查询能力还打不到 NoSQL 的水平，更别提 SQL 的复杂应用。所以在实际的应用中，区块链不能替代数据，只能互补。
所以在项目实施前，仔细想想自己需求，真的需要区块链吗？还是需要区块链上的一些特性？例如数据不可撰改。如果仅仅是需要区块链的某一个特性。我们可以针对这个需求，思考一下能否使用传统数据库解决。
既然区块链替代不了传统数据库，那么必然要在项目中同时使用两种技术。这样问题来了，会有两份数据，一份存储在链下，即传统数据库，另外一部分数据上链，这样就有两份重复的数据，那么怎样保证他们的一致性呢？
非链上的原生资产在上链过程中，有一个重要的问题：原生资产的真实性问题，即链上资产、链下资产如何保持一致性问题。
区块链和比特币网络不同，比特币是在链上产生的，它与区块链密布可分，是一体的，所以它的数据安全性是自闭环的。而我们的链下数据并不是在区块链中产生的，将链下数据与区块链对接上链
我们需要考虑几个问题
怎样能保证数据的真实和一致性呢？
当出现不一致的时候以哪个为准呢？
当需要读取数据时，是走连上，还是链下呢？
什么数据上链，什么数据不上链？
下面回答上面提出的问题
两端都将数据做一次hash，可以快速对比是否数据一致
我认为以连上数据为准较好，因为数据库数据更容易被撰改。
前台走上链，后台走数据库，前台是为用户提供服务的，所以要走连上数据，后台是管理的，可以直接走数据库，然后保证数据库与区块链数据一致。
共享数据上链，私有数据不上链，想象一下在盟链系统中，需要共享给其他成员数据，之前采用 Api接口，有了区块链更好的解决了资源共享问题。
例如下图我们将共享数据上链，在联盟中共享。私有数据（不能公开的数据）放到自己本地数据库，或者私链中。
盟链系统
+----------+ +----------+ +----------+
| 你 | | 我 | | 他 |
+----------+ +----------+ +----------+
| | |
V V V
+------------------------------------+
| Block Chain |
+------------------------------------+