19C 仓储/资源重组时间过长
集团要集中采购一批存储,本次测试的存储是DELL&EMC的Powerflex存储,本来定的压测目标等,但是在其中一个场景断掉计算节点后,起库时间巨长,进行了相关的分析,如下是一些粗浅的步骤,好记性不如烂笔头。记录一下
2024-09-24T14:31:42.636014+08:00
Starting ORACLE instance (normal) (OS id: 80696)
2024-09-24T14:31:42.746937+08:00
PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)
2024-09-24T14:31:42.746964+08:00
4K Configured 39 39 NONE
2024-09-24T14:31:42.747012+08:00
2048K 266246 262145 262145 NONE
2024-09-24T14:31:42.747038+08:00
**********************************************************************
2024-09-24T14:32:06.212071+08:00
Increasing priority of 26 RS
* Setting GES domain 0
Attached to domain 0 (addr: 0xe3498eeb8)
Reconfiguration started (old inc 0, new inc 12)
Dynamic remastering is disabled
List of instances (total 2) :
1 2
My inst 1 (I'm a new instance)
Global Resource Directory frozen
Enabling Dynamic Remastering: NONE->NORM switch
Communication channels reestablished
2024-09-24T14:32:06.259101+08:00
* domain 0 valid = 1 (flags x8820, pdb flags x8000) according to instance 2
2024-09-24T14:32:06.287062+08:00
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
2024-09-24T14:32:06.291798+08:00
LMS 15: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291808+08:00
LMS 17: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291810+08:00
LMS 5: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291814+08:00
LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291818+08:00
LMS 19: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291821+08:00
LMS 3: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291826+08:00
LMS 4: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291833+08:00
LMS 22: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291856+08:00
LMS 7: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291863+08:00
LMS 20: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291919+08:00
LMS 25: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291923+08:00
LMS 14: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291942+08:00
LMS 12: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291945+08:00
LMS 6: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291966+08:00
LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291975+08:00
LMS 24: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291976+08:00
LMS 16: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291980+08:00
LMS 11: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291983+08:00
LMS 21: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291988+08:00
LMS 23: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291990+08:00
LMS 9: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291993+08:00
LMS 10: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291994+08:00
LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.291996+08:00
LMS 18: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.292004+08:00
LMS 13: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2024-09-24T14:32:06.292009+08:00
LMS 8: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
Set master node info
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
2024-09-24T14:37:55.980243+08:00
Reconfiguration complete (total time 349.8 secs) <<<<<<<<<<<<<<<<<<<<
Decreasing priority of 26 RS
2024-09-24T14:37:55.980646+08:00
Starting background process LCK0
可以看见,在alert日志中有Reconfiguration complete (total time 349.8 secs) 的提示,在我们标准化的系统中是没有过的。
通过alert日志得到,当时LMON的进程ID为81255,我们可以去当时的TRC下找找原因
2024-09-24T14:31:57.273227+08:00
LMON started with pid=22, OS id=81255
Trace file /u01/app/oracle/diag/rdbms/flexdbt/flexdbt1/trace/flexdbt1_lmon_81255.trc
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.24.0.0.0
Build label: RDBMS_19.24.0.0.0DBRU_LINUX.X64_240627
ORACLE_HOME: /u01/app/oracle/product/19.3.0/db
System name: Linux
Node name: flexdbt1
Release: 4.18.0-477.10.1.el8_8.x86_64
Version: #1 SMP Wed Apr 5 13:35:01 EDT 2023
Machine: x86_64
CLID: P
Instance name: flexdbt1
Instance number: 1
Database name: flexdbt
Database unique name: flexdbt
Database id: N/A
Redo thread mounted by this instance: 0 <none>
Oracle process number: 22
Unix process pid: 81255, image: oracle@flexdbt1 (LMON)
2024-09-24 14:32:06.226 : * Begin lmon rcfg step KJGA_RCFG_BEGIN (kjidomena 0, rcfginfo x0)
2024-09-24 14:32:06.229 : * Begin lmon rcfg step KJGA_RCFG_FREEZE
2024-09-24 14:32:06.230 : * Begin lmon rcfg step KJGA_RCFG_COMM
2024-09-24 14:32:06.238 : * Begin lmon rcfg step KJGA_RCFG_EXCHANGE (kjidomena 0, hvmaster 2)
2024-09-24 14:32:06.287 : * Begin lmon rcfg step KJGA_RCFG_ENQCLEANUP
2024-09-24 14:32:06.288 : * Begin lmon rcfg step KJGA_RCFG_CLEANUP
2024-09-24 14:32:06.363 : * Begin lmon rcfg step KJGA_RCFG_TIMERQ
2024-09-24 14:32:06.363 : * Begin lmon rcfg step KJGA_RCFG_DDQ
2024-09-24 14:32:06.363 : * Begin lmon rcfg step KJGA_RCFG_SETMASTER
2024-09-24 14:32:06.737 : * Begin lmon rcfg step KJGA_RCFG_ENQREPLAY
2024-09-24 14:32:06.754 : * Begin lmon rcfg step KJGA_RCFG_ENQDUBIOUS
2024-09-24 14:32:06.765 : * Begin lmon rcfg step KJGA_RCFG_ENQGRANT
2024-09-24 14:32:06.773 : * Begin lmon rcfg step KJGA_RCFG_PCMREPLAY <<<<<
2024-09-24 14:37:55.697 : * Begin lmon rcfg step KJGA_RCFG_FIXWRITES
2024-09-24 14:37:55.979 : * Begin lmon rcfg step KJGA_RCFG_END (kjidomena 0)
Total dlm rcfg time (inc 12): 341.557 secs (1681687, 2023244)
Begin step .........: 0.002 secs (1681687, 1681689)
Freeze step ........: 0.000 secs (1681690, 1681690)
Remap step .........: 0.001 secs (1681690, 1681691)
Comm step ..........: 0.005 secs (1681691, 1681696)
Sync 1 step ........: 0.003 secs (1681696, 1681699)
Exchange step ......: 0.000 secs (1681699, 1681699)
Sync 2 step ........: 0.046 secs (1681700, 1681746)
Enqueue cleanup step: 0.002 secs (1681746, 1681748)
Sync pcm1 step .....: 0.000 secs (1681748, 1681748)
Cleanup step .......: 0.073 secs (1681748, 1681821)
Timerq step ........: 0.000 secs (1681821, 1681821)
Ddq step ...........: 0.000 secs (1681821, 1681821)
Set master step ....: 0.002 secs (1681821, 1681823)
Sync 3 step ........: 0.364 secs (1681823, 1682187)
Enqueue replay step : 0.002 secs (1682187, 1682189)
Sync 4 step ........: 0.014 secs (1682189, 1682203)
Enqueue dubious step: 0.002 secs (1682203, 1682205)
Sync 5 step ........: 0.009 secs (1682205, 1682214)
Enqueue grant step .: 0.005 secs (1682214, 1682219)
Sync 6 step ........: 0.003 secs (1682219, 1682222)
PCM replay step ....: 0.098 secs (1682222, 1682320)
Sync 7 step ........: 340.647 secs (1682320, 2022967)
Fixwrt replay step .: 0.276 secs (2022967, 2023243)
Sync 8 step ........: 0.000 secs (2023244, 2023244)
End step ...........: 0.000 secs (2023244, 2023244)
Number of replayed enqueues sent / received .......: 0 / 2232
Number of replayed fusion locks sent / received ...: 0 / 13601328
Number of enqueues mastered before / after rcfg ...: 0 / 2002
Number of fusion locks mastered after rcfg: 13601328
Number of affinity locks expanded remote / local ..: 0 / 0
Number of kjbr resources scanned / kjbr buckets skipped in cleanup step ..: 13601328 / 1664
Reconfiguration 大约有 340 秒花在 KJGA_RCFG_PCMREPLAY 步骤上了,该步骤的含义是
Transfer of the local lock information to the new master.
也就是新实例(实例 1)启动后,现存实例(实例 2) 把其现存的 resource master 的信息分发给 新实例的过程。
根据 OSWatcher,系统在 14:32 到 14:37 出现大幅度的 IpReasmFails 增长。
$ awk '/zzz/{t=$5}/IpReasmFails/{print t,$1,$2}' flexdbt1_netstat_24.09.24.1400.dat
14:31:02 IpReasmFails 1703436
14:31:32 IpReasmFails 1703436
14:32:02 IpReasmFails 1703436
14:32:32 IpReasmFails 1868043
14:33:02 IpReasmFails 2069652
14:33:32 IpReasmFails 2269260
14:34:02 IpReasmFails 2468103
14:34:32 IpReasmFails 2667326
14:35:02 IpReasmFails 2866252
14:35:32 IpReasmFails 3065929
14:36:02 IpReasmFails 3265551
14:36:32 IpReasmFails 3465252
14:37:02 IpReasmFails 3665142
14:37:32 IpReasmFails 3861132
14:38:02 IpReasmFails 3975386
14:38:32 IpReasmFails 3975394
14:39:02 IpReasmFails 3975395
14:39:32 IpReasmFails 3975395
14:40:02 IpReasmFails 3975395
Jumbo Frames 能减少 UDP fragmentation reassembly 的发生,从而能有效避免 IpReasmFails
eno145: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::2eea:7fff:feed:e6c8 prefixlen 64 scopeid 0x20<link>
ether 2c:ea:7f:ed:e6:c8 txqueuelen 1000 (Ethernet)
RX packets 67856043 bytes 123641995882 (115.1 GiB)
RX errors 0 dropped 6 overruns 0 frame 0
TX packets 77358134 bytes 96528195964 (89.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 70
To implement the solution, please execute the following steps:
对所有节点的私网设备 (eno145) 启用 Jumbo Frames,参考:
Recommendation for the Real Application Cluster Interconnect and Jumbo Frames ( Doc ID 341788.1 )
注意启用 Jumbo Frames 需要网络设备及交换机支持
ifconfig eno145 mtu 9000
vi/etc/sysconfig/network-scripts/ifcfg-eno145
MTU=9000
修改MTU后,netstat记录中我们再看看
[root@flexdbt1:/u01/app/grid/oracle.ahf/data/repository/suptools/flexdbt1/oswbb/grid/archive/oswnetstat]$ awk '/zzz/{t=$5}/IpReasmFails/{print t,$1,$2}' flexdbt1_netstat_24.09.25.1500.dat
15:00:28 IpReasmFails 2875075
15:00:58 IpReasmFails 2875075
15:01:29 IpReasmFails 2875075
15:01:59 IpReasmFails 2875075
15:02:29 IpReasmFails 2875075
15:02:59 IpReasmFails 2875075
15:03:29 IpReasmFails 2875075
15:03:59 IpReasmFails 2875075
15:04:29 IpReasmFails 2875075
15:04:59 IpReasmFails 2875075
15:05:29 IpReasmFails 2875075
15:05:59 IpReasmFails 2875075
15:06:29 IpReasmFails 2875075
15:06:59 IpReasmFails 2875075
15:07:29 IpReasmFails 2875075
15:07:59 IpReasmFails 2875075
15:08:29 IpReasmFails 2875075
15:08:59 IpReasmFails 2875075
15:09:29 IpReasmFails 2875075
15:09:59 IpReasmFails 2875075
15:10:29 IpReasmFails 2875075
15:10:59 IpReasmFails 2875075
15:11:29 IpReasmFails 2875075
15:11:59 IpReasmFails 2875075
15:12:29 IpReasmFails 2875075
15:12:59 IpReasmFails 2875075
15:13:29 IpReasmFails 2875075
15:13:59 IpReasmFails 2875075
15:14:29 IpReasmFails 2875075
15:14:59 IpReasmFails 2875075
15:15:29 IpReasmFails 2875075
15:15:59 IpReasmFails 2875075
15:16:29 IpReasmFails 2875075
15:16:59 IpReasmFails 2875075
15:17:29 IpReasmFails 2875075
15:17:59 IpReasmFails 2875075
15:18:29 IpReasmFails 2875075
15:18:59 IpReasmFails 2875075
15:19:29 IpReasmFails 2875075
15:19:59 IpReasmFails 2875075
15:20:30 IpReasmFails 2875075
15:21:00 IpReasmFails 2875075
15:21:30 IpReasmFails 2875075
15:22:00 IpReasmFails 2875075
15:22:30 IpReasmFails 2875075
15:23:00 IpReasmFails 2875075
15:23:30 IpReasmFails 2875075
15:24:00 IpReasmFails 2875075
15:30:20 IpReasmFails 0
15:30:50 IpReasmFails 0
15:31:20 IpReasmFails 0
15:31:50 IpReasmFails 0
15:32:20 IpReasmFails 0
15:32:50 IpReasmFails 0
15:33:20 IpReasmFails 0
15:33:50 IpReasmFails 0
15:34:20 IpReasmFails 0
15:34:50 IpReasmFails 0
15:35:20 IpReasmFails 0
15:35:50 IpReasmFails 0
15:36:20 IpReasmFails 0
15:36:50 IpReasmFails 0
15:37:20 IpReasmFails 0
15:37:50 IpReasmFails 0
15:38:20 IpReasmFails 0
15:38:50 IpReasmFails 0
15:39:20 IpReasmFails 0
15:39:50 IpReasmFails 0
15:40:20 IpReasmFails 0
15:40:50 IpReasmFails 0
15:41:20 IpReasmFails 0
15:41:50 IpReasmFails 0
15:42:20 IpReasmFails 0
15:42:50 IpReasmFails 0
15:43:20 IpReasmFails 0
15:43:50 IpReasmFails 0
15:44:20 IpReasmFails 0
15:44:50 IpReasmFails 0
15:45:20 IpReasmFails 0
15:45:50 IpReasmFails 0
15:46:20 IpReasmFails 0
15:46:51 IpReasmFails 0
15:47:21 IpReasmFails 0
15:53:53 IpReasmFails 0
15:54:23 IpReasmFails 0
15:54:53 IpReasmFails 0
15:55:23 IpReasmFails 0
15:55:53 IpReasmFails 0
15:56:23 IpReasmFails 0
15:56:53 IpReasmFails 0
15:57:23 IpReasmFails 0
15:57:53 IpReasmFails 0
15:58:23 IpReasmFails 0
15:58:53 IpReasmFails 0
15:59:23 IpReasmFails 0
15:59:53 IpReasmFails 0
同时资源重组的时间,也降了下来。起库时间也快了很多
2024-09-25T15:56:17.445405+08:00
Reconfiguration complete (total time 5.9 secs)
上一篇: Java 的可选用法学习
下一篇: 探索数学之美:亲和数字与计划实施
推荐阅读
-
19C 仓储/资源重组时间过长
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。