特朗普被社交媒体封禁后：第一修正案、诉讼与三笔和解
2021 年 1 月 6 日国会山骚乱之后，特朗普究竟被多少个平台封禁？平台是不是违反了美国宪法第一修正案？他后来通过诉讼拿回账号了吗？到了 2025 年，Meta、X 和 YouTube 又为什么先后付钱和解？ 这些问题常被压缩成一句话：科技公司当年封错了，所以后来赔钱认错。公开判决与和解文件并不支持这种概括。 按“直接限制特朗普本人账号”的严格口径计算，涉及 6 个平台产品，由 5 家公司运营。特朗普确实可以起诉，也确实请求法院恢复账号，但第一修正案通常只约束政府，不直接约束私人平台。他对 Twitter 的核心宪法主张在 2022 年被联邦地区法院驳回。2025 年出现的三笔和解没有包含平台承认违法，也没有形成判定封禁违宪的司法先例。 本文资料更新至 2026 年 9 月 2 日。 一、到底是 6 个、5 家，还是 17 个 “特朗普被多少个社交媒体封号”没有一个脱离统计口径的唯一答案。 如果只计算国会山事件后直接限制特朗普本人账号的主流平台产品，可以列出 6 个：Twitter、Facebook、Instagram、YouTube、Snapchat 和 Twitch。Fa...
深入 HBase 19 - HBase 3.0 与设计边界
HBase 3.0.0 是大版本升级，不应被写成 2.6 的小补丁。官方下载页显示 3.0.0 发布于 2026-08-05，同时 2.6.6 发布于 2026-06-09，2.5.15 被标为 stable release。基础机制仍可用 2.6.6 解释，但 3.0 的部署、客户端连接和 API 兼容边界必须单独处理。 本篇只抓一个核心问题：3.0 相对 2.6 改了什么；哪些工作负载应该选别的数据库。 版本位置图 flowchart TD A[HBase 2.6.6 基础机制] --> B[row key / Region / WAL / MemStore / HFile] B --> C[2.x 客户端与运维习惯] C --> D[HBase 3.0.0 大版本升级] D --> E[JDK 17+] D --> F[Hadoop 2 移除] D --> G[MasterRegistry/RPC bootstrap 默认路径] D --> H[deprecated/private API 清理] H...
深入 HBase 18 - Metrics、hbtop、Compaction 与性能调优
HBase 性能问题很少只由一个参数造成。热点 Region、StoreFile 过多、compaction backlog、BlockCache 命中率下降、GC 停顿、HDFS locality 变差，都会表现成读写延迟上升。调优的第一步不是改配置，而是把症状映射到可观察对象。 本篇只抓一个核心问题：如何用 Metrics、hbtop、JMX 和服务端状态识别热点 Region、compaction backlog、缓存失配、GC 和磁盘瓶颈。 观察路径图 flowchart TD Slow[读写变慢] --> Client[Client retry/timeout] Slow --> RS[RegionServer metrics] RS --> Hot[Region #REQ/S/#WRITE/S] RS --> Cache[BlockCache hit/miss] RS --> Store[#SF / StoreFile size] RS --> Compaction[Compaction queue/prog...
深入 HBase 17 - Kerberos、RPC 保护与 ACL
HBase 安全不是一个开关。Kerberos 解决身份认证，RPC protection 解决传输层保护，ACL 解决 HBase 资源授权，HDFS 和 ZooKeeper 还要各自按安全模式配置。任何一层缺失，生产集群都会留下绕过路径。 本篇只抓一个核心问题：客户端身份、服务认证、传输保护和表权限如何衔接。 安全路径图 flowchart TD Client[Client principal] --> KDC[Kerberos KDC] RS[RegionServer principal] --> KDC Master[HMaster principal] --> KDC Client --> RPC[HBase RPC/SASL] RPC --> AuthN[authentication] AuthN --> Protection[hbase.rpc.protection] Protection --> ACL[AccessController ACL] ACL --> Region[Regi...
深入 HBase 16 - Coprocessor、Endpoint 与 Phoenix 边界
Coprocessor 把一部分逻辑放进 HBase 服务端进程执行。这个能力很强，也很危险：代码和 RegionServer 在同一个 JVM、同一套权限、同一条请求路径里运行。Endpoint 能做局部聚合和自定义 RPC，但它不是分布式 SQL 引擎；Phoenix 提供 SQL 层，但 Phoenix 和 HBase 的升级边界也不能混写。 本篇只抓一个核心问题：计算下推能做什么，何时会破坏隔离、升级和运维边界。 Coprocessor 路径图 flowchart TD Client[HBase Client] --> RPC[RegionServer RPC] RPC --> Observer[Observer hooks] Observer --> Region[Region] Region --> Store[Store/MemStore/HFile] Client --> Endpoint[Endpoint service] Endpoint --> Region Region --> WAL[...
深入 HBase 15 - BufferedMutator 与 Bulk Load
在线批量写和 Bulk Load 解决的是同一个输入问题：大量记录要进入同一张 HBase 表。二者的成本模型完全不同。BufferedMutator 仍然走 RegionServer 写入协议，写入进入 WAL、MemStore、flush 和 compaction；Bulk Load 先离线生成合法 HFile，再让运行中的 RegionServer 接管这些 StoreFile。 本篇只抓一个核心问题：什么时候该用在线批量写，什么时候该先生成 HFile；两条路径各自把 CPU、网络、WAL、MemStore 和 compaction 成本放在哪里。 两条批量写路径图 flowchart LR A[应用批量记录] --> B[BufferedMutator] B --> C[RegionServer RPC] C --> D[WAL] C --> E[MemStore] E --> F[flush] F --> G[HFile] A --> H[MapReduce/Spark 预排序] H -->...
深入 HBase 14 - Get、Scan、Filter 与分页
前置问题与边界 HBase 的读请求不是“把表读出来再过滤”。Get 直接定位单行；Scan 按 row-key range 顺序推进；Filter 可以减少返回给客户端的 Cell，也可能在服务端继续扫描大量数据。caching、batch、limit 和 reversed 影响 RPC 粒度、结果分片和遍历方向，但不会改变 HFile 的物理排序。 本篇回答一个核心问题：scan range、cache、batch、limit、reversed scan 如何影响 RPC 和结果语义。BlockCache、Bloom Filter 和 HFile block 在第 05、06 篇；row key 设计在第 03 篇；Coprocessor 和 Phoenix 边界在第 16 篇。 读取路径图 flowchart TD C[Client] --> O{Operation} O -->|Get row| G[Single row lookup] O -->|Scan range| S[Region scanner] ...
深入 HBase 13 - Snapshot、Backup 与恢复
前置问题与边界 HBase Snapshot 接近一次元数据操作，因为它主要记录某个时刻表的 Region、StoreFile 引用和相关描述，而不是把整张表的数据复制一遍。HFile 是不可变文件，这让 snapshot 可以通过引用既有 HFile 建立一致视图；后续 compaction、删除和清理要尊重这些引用。 本篇回答一个核心问题：Snapshot 为什么快，Backup 和跨集群恢复还需要什么。第 11 篇处理 WAL 恢复，第 12 篇处理 replication；本篇处理表级时间点视图、克隆、恢复和备份边界。 Snapshot 路径图 flowchart TD A[Table] --> B[Regions] B --> C[StoreFiles HFile] A --> D[Snapshot request] D --> E[Flush by default] E --> F[Snapshot manifest] F --> G[References to HFiles] ...
深入 HBase 12 - 跨集群 Replication
前置问题与边界 HBase 跨集群 Replication 复制的是 WAL edit。源集群的 RegionServer 把符合条件的 edit 放入复制队列，由 replication source 推送到 peer 集群。这个过程是异步的，常用于容灾、迁移、异地读和下游同步；它不把两个集群变成一个强一致数据库。 本篇回答一个核心问题：WAL edit 如何异步复制，顺序、延迟、冲突和故障切换的边界是什么。RegionServer 崩溃后的本地 WAL 恢复见第 11 篇；Snapshot 和 Backup 见第 13 篇。 复制路径图 flowchart LR A[Client write] --> B[Source RegionServer] B --> C[Source WAL] C --> D[Replication queue] D --> E[ReplicationSource] E --> F[Peer cluster RPC] F --> G[Sink RegionServer...
深入 HBase 11 - RegionServer 崩溃与 WAL 恢复
前置问题与边界 RegionServer 崩溃以后，HBase 要恢复的是由该 RegionServer 服务的 Region，而不是让 HDFS 自动懂得数据库事务。HDFS 负责保存 WAL 和 HFile；HBase 通过 procedure、assignment、WAL split 或 replay，把未 flush 的 edit 重新送到负责 Region 的服务进程。 本篇回答一个核心问题：ServerCrashProcedure、WAL split/replay 和 Region reassignment 如何把服务恢复到可读写状态。行级一致性边界见第 10 篇；复制链路见第 12 篇；Snapshot 和 Backup 见第 13 篇。 崩溃恢复路径图 flowchart TD A[RegionServer crash] --> B[Master detects dead server] B --> C[ServerCrashProcedure] C --> D[Mark affected regions unavaila...