技术

一、前言 & 场景痛点 在网络仿真学习场景中，很多用户会使用 Linux KVM 运行Windows虚拟机，并在Windows内部安装 VirtualBox + HCL华三模拟器 做网络实验。 默认KVM为NAT模式（virbr0，192.168.122.0/24），会出现典型网络隔离问题： ✅ Linux宿主机可以正常访问Windows虚拟机 ✅ Windows虚拟机可以正常访问内部HCL模拟设备（192.168.56.0/24） ❌ Linux宿主机无法直接访问HCL模拟器设备，必须远程桌面进入Windows操作，极其繁琐 核心问题：KVM NAT网络二层隔离，且Windows内部VirtualBox Host-Only网段（192.168.56.0/24）无法被宿主机路由穿透。 本文提供一套全Linux发行版通用的终极解决方案：KVM桥接组网 + Windows三层转发 + 双向静态路由，实现宿主机直接Telnet/SSH/Web访问HCL所有虚拟设备。 二、整体网络拓扑 物理局域网网段：192.168.31.0/24 HCL模拟设备网段：192.168.56.0/24 1Linux宿主机（br0：192.168.31.13） 2 ↓ KVM二层桥接 3Windows虚拟机（桥接网卡：192.168.31.159） 4 ↓ Windows内核IP转发 5Windows VirtualBox Host-Only网卡（192.168.56.1） 6 ↓ 7HCL交换机/路由器（192.168.56.99 等设备） 三、核心实现原理 KVM改桥接模式：让Windows虚拟机成为局域网独立设备，与宿主机二层互通 开启Windows内核IP转发：让Windows充当三层软路由，打通两张网卡跨网段流量 Linux宿主机配置静态路由：将56网段流量全部转发至Windows虚拟机 HCL设备配置回程路由：解决流量出去回不来的核心坑点 四、Linux宿主机配置（全发行版通用） 适配 Fedora、Ubuntu、Debian、Arch 等所有Linux系统，区分主流网络管理器方案。 ...

什么是vlan？ Virtual Local Area Network，虚拟局域网 定义是在物理交换机上逻辑隔离的虚拟局域网 vlan的本质是 给数据帧打标签（Tag） 交换机转发以太网帧时，在帧头插入 4 字节 VLAN 标签，标签里携带VLAN ID（1–4094），然后在这个广播域里泛洪。 为什么要有vlan技术？ 隔离广播 没有 VLAN 时，全网一个广播域： 电脑开机 DHCP、ARP 查询、病毒广播报文会传遍所有设备。终端越多，广播流量越大，严重占用带宽、卡顿甚至瘫痪网络（广播风暴）。 VLAN 切割广播域，广播只在组内流转，大幅减少无效流量，提升网络稳定性。 安全隔离 不同业务 / 部门天然需要隔离： 财务部服务器不能被市场部电脑随意访问； 办公网不能直接访问服务器区、监控网； 不同 VLAN 二层完全不通，天然形成安全边界，不配置三层路由就无法互相访问，减少攻击、数据泄露风险。 简化网络规划，节约硬件成本 无需为每个部门单独采购交换机、单独布线； 同一台交换机承载多套业务网络，降低设备、布线、机柜成本； 人员工位变动不用重新改网线，交换机上修改 VLAN 配置即可切换网段。 通过 VLAN 标签分割二层广播域 VLAN转发过程 阶段 1：PC1 发送报文到 SW1 Access 口 PC1 发出无 Tag数据帧； 进入 SW1 Access VLAN10 端口，交换机给帧添加 VLAN 10 Tag； SW1 学习源 MAC（PC1-MAC）：MAC 表记录 PC1-MAC + 入端口 + VLAN10； 查找 MAC 地址表，发现目的 MAC（PC3-MAC）不在本交换机端口，需要从 Trunk 口转发。 阶段 2：跨交换机传输 Trunk 口规则：VLAN10 不是 Native VLAN，保留 Tag 10 发送出去； 报文带着 802.1Q 标签在交换机之间传输。 ...

声明：本文章根据 小林coding 图解mysql进行些许改编。侵权删。本文持续更新。 索引篇 什么是索引 当你想查阅书中某个知识的内容，你会选择一页一页的找呢？还是在书的目录去找呢？ 傻瓜都知道时间是宝贵的，当然是选择在书的目录去找，找到后再翻到对应的页。书中的目录，就是充当索引的角色，方便我们快速查找书中的内容，所以索引是以空间换时间的设计思想。 那换到数据库中，索引的定义就是帮助存储引擎快速获取数据的一种数据结构，形象的说就是索引是数据的目录。 下图是 MySQL 的结构图，索引和数据就是位于存储引擎中： 索引分类 按「数据结构」分类 B+tree索引、Hash索引、Full-text索引。 按「物理存储」分类 聚簇索引（主键索引）、二级索引（辅助索引）。 主键索引的 B+Tree 的叶子节点存放的是实际数据，所有完整的用户记录都存放在主键索引的 B+Tree 的叶子节点里； 二级索引的 B+Tree 的叶子节点存放的是主键值，而不是实际数据。 所以，在查询时使用了二级索引，如果查询的数据能在二级索引里查询的到，那么就不需要回表，这个过程就是覆盖索引。如果查询的数据不在二级索引里，就会先检索二级索引，找到对应的叶子节点，获取到主键值后，然后再检索主键索引，就能查询到数据了，这个过程就是回表。 按「字段特性」分类 主键索引、唯一索引、普通索引、前缀索引。 唯一约束（UNIQUE KEY）就是一种索引 所以主键就是索引。。 ON DUPLICATE KEY UPDATE 提供无则插入、有则更新 的原子性upsert命令，避免先查再写的并发问题。 常用于实现幂等写入，但不属于乐观锁。 MySQL 在执行 INSERT ... ON DUPLICATE KEY UPDATE 后，会返回一个整数值告诉你有多少行被影响了。 规则如下（重要，正是因为这里容易错）： 实际发生的情况 affected_rows 说明 真正插入了一条新记录 1 原来没有这行，插入成功 更新了一条记录，并且数据真的被修改了 2 冲突后走 UPDATE，且字段值确实变了 更新了一条记录，但数据没有任何变化 0 冲突后走 UPDATE，但 SET 后的值和原来一样 按「字段个数」分类 单列索引、联合索引。 B+Tree B+Tree 是一种多叉树，叶子节点才存放数据，非叶子节点只存放索引，而且每个节点里的数据是按主键顺序存放的。每一层父节点的索引值都会出现在下层子节点的索引值中，因此在叶子节点中，包括了所有的索引值信息，并且每一个叶子节点都有两个指针，分别指向下一个叶子节点和上一个叶子节点，形成一个双向链表。 图有误，叶子节点是双向链表 通过主键查询商品数据的过程: 比如，我们执行了下面这条查询语句： ...

概念定义 到底什么是并发 并发 = 多个操作在同一时间窗口内同时进行，无论来自同一人还是不同人。 因为数据只有一份，多人同时操纵就会有风险：谁说了算呢？所以会产生竟态问题。cpu的并发就是最好的理解方式了：cpu核只有一个的情况下，不可能同一时刻给多人使用，所以只能大家轮着时间切片用。 一条数据会不会在同一时刻被两个操作同时修改？是的话就是存在并发问题。 什么是分布式 分布式：系统本身被拆分成了多个服务/节点。系统架构是分散的 一个人讲话给自己听，很难搞错； 三个人ABC一起传话，中间的B听错了，那传到C耳朵里的就变了。大家拿着的信息不一样了，所以分布式场景就是要解决怎么尽量去统一大家信息的问题。 什么是幂等 幂等就是：同一个操作，执行一次和多次，结果不变。 为什么我要单独把他拎出来讲？因为不幂等的设计，既是并发问题，也是分布式问题。 并发如何体现： 多个人同时下单; 一个人同一时刻点赞十次; 分布式如何体现： 项目有三个角色，分别是生产者、MQ、消费者; 还可能是更复杂的微服务项目; 通用分析方法 首先我想声明一句： 在分布式并发问题中，任何不根据具体情景分析，只讲技巧的，都是耍流氓！并发场景信息杂糅、需求各不一致。技术本身是为了解决问题的，脱离了真实情况的技术毫无用处，反而成了心智负担。 四个问题，四个数 遇到一个百万级QPS以内的分布式、并发场景，依次问四个问题，就能精准锁定架构与技术方案方向： 1. 人数 这个操作是 “单人” 还是 “多人”？ 单人操作（比如用户修改自己的头像）：不会有多人写冲突，只可能有重复提交（浏览器重试），用幂等键就够了（如 Redis SETNX）。 多人操作（比如点赞、关注、下单扣库存）：有并发争抢、写冲突风险。 2. 数据库行数 & 表数 这个操作是 “单行单表数据” 还是 “多行 / 跨表数据”？ 单行单表（点赞计数、关注关系）：数据库层的唯一索引 + 状态字段可以直接解决。 多行或跨表（下单：扣库存→生成订单→扣钱）：数据库行锁或乐观锁（version） 是核心，唯一索引只能防重复记录，但防不了库存超卖。 3. 重试数 错误可以 “直接返回” 还是必须 “排队等待”？也就是业务对失败的容忍度如何？ 可以直接返回 “请稍后重试”（如点赞冲突、重复领券）：用乐观锁或唯一键冲突，返回失败由客户端自行重试。 必须排队串行执行、不能失败丢弃（如秒杀扣库存、限量抢购）：用行锁或消息队列串行化，牺牲部分吞吐，强保数据不出错。 4. 一致数 业务需要 “强一致性” 还是 “最终一致性”？ 强一致性（转账、钱包扣款、资金交易）：必须即时数据一致，不能异步兜底，要用分布式事务、行锁、悲观锁，不能靠异步补偿。 最终一致性（普通下单、发积分、返优惠券、日志统计）：允许短暂数据不一致，可异步慢慢补齐，优先用MQ 异步、本地消息表、事务消息解耦，提升吞吐与可用性。 情景演练 情景一：关注 / 取关 问题 答案 人数 多人操作（多人同时对同一博主关注/取关，粉丝数共享） 表数 单行单表（核心socials一行，accounts计数的更新属于事务外 MQ） 重试 直接返回成功（重复操作不报错，与幂等一致） 一致性 核心强一致（关系状态原子翻转），计数最终一致（MQ 异步） ...

核心权衡点：锁的量级与性能损耗的权衡 选择哪种并发控制或一致性手段，本质是在 一致性强度 与 系统吞吐 / 延迟 之间做交易。不存在普适最优解，只有基于回源成本、并发量级和跨实例协调代价的按需组合。 量级轻 → 延迟低，但保护弱：进程内 singleflight，非阻塞软标记，纯 TTL 过期。 量级重 → 一致性强，但代价高：跨实例分布式锁，强同步写穿透。 下面从“数据流”与“控制面”两个维度梳理关键技术，并给出组合原则。 1. 数据一致性模式（如何同步缓存与数据库） 这些模式关注当源数据变更时，缓存如何更新或失效，不直接涉及并发控制，但影响选型。 Cache Aside（旁路缓存） 模式：读未命中则查 DB 并回写缓存；写直接更新 DB，然后删除缓存。 锁量级：写操作无锁，仅单一 DEL；读可配合 singleflight 防击穿。 权衡：最终一致窗口 = 删缓存到下次重建之间；删除失败需重试或 TTL 兜底。 适用：读多写少，可接受短暂不一致的场景（大多数互联网业务）。 Read/Write Through（读写穿透） 模式：缓存层代理所有 DB 读写，业务只与缓存交互。 锁量级：同步写，需保证缓存与 DB 的原子更新，往往引入分布式锁或事务消息。 权衡：一致性强，但每次写都要同时操作缓存+DB，写入延迟高，实现复杂。 Write Behind（异步回写） 模式：写只更新缓存，异步批量刷回 DB。 锁量级：缓存写入轻量，但需要队列/日志保证不丢数据。 权衡：写入性能极高，一致性很弱，允许丢数据窗口。 延迟双删与订阅刷新 延迟双删：写 DB 前先删缓存，DB 更新完成后延迟再删一次（用于规避主从延迟导致的不一致）。 Binlog 订阅（如 Canal）：异步监听 DB 变更流水，精确删除或更新缓存。 锁量级：均为异步，无额外锁竞争，但引入消息延迟和架构复杂度。 本系统选择：Cache Aside + MQ 异步删除，利用已有死信队列保障最终一致性，兼顾简单和可靠。 2. 并发控制机制（如何防击穿、防并发重建） singleflight（进程内请求合并） 量级：极轻，无网络开销，仅内存 map + 阻塞等待。 保护范围：单进程内相同请求的合并。 性能损耗：少数请求等待首次执行完毕，延迟可忽略。 适用：高并发下同一批缓存键临时穿透 Redis 的场景。 分布式锁（如 Redis SET NX EX） 量级：重，涉及网络往返、轮询等待、锁 TTL 管理和 Lua 释放。 保护范围：跨实例互斥，确保单点重建。 性能损耗：锁竞争导致额外延迟（轮询 100ms+），可能成为瓶颈。 适用：回源成本极其高昂且要求强一致的场景（如复杂报表、详情缓存重建）。 软标记 / SETNX 提示（非阻塞跨实例通知） 量级：极轻，一次 Redis SETNX 无等待。 保护范围：跨实例“知情权”，让其他实例主动降级而非常规等待。 性能损耗：基本无延迟，仅需判断标记存在与否。 适用：重建允许降级或短暂不一致的场景（批量读、冷缓存预热）。 仅靠 TTL 量级：无。 保护：无任何并发控制。 损耗：零，但可能发生缓存击穿或雪崩。 适用：数据可大量容忍陈旧，或变更极低频。 3. 组合决策矩阵 场景 回源成本 推荐组合 理由 视频实体批量读取（高频、可降级） 中（批量主键查询） singleflight + 软标记 进程内去重 + 跨实例非阻塞防多余穿透 视频详情页读取（中频、不期望旧数据） 中高（复杂 SQL 或关联查询） 分布式锁 + double-check 强控单实例重建，避免多实例重复计算 关注流冷缓存重建（低频、允许最终一致） 高（多表聚合排序） 软标记 + 单一执行 不强制等待，接受少量重复重建成本优于锁等待 写操作后缓存失效（Cache Aside） 极低（DEL 命令） 无需锁，直接 DEL 并发写由 DB 串行化，缓存仅打扫战场 4. 一句话选型指南 先上 singleflight，解决绝大多数进程内并发穿透。 多实例部署且重建轻量时，补 软标记 提示降级，避免引入锁。 只有当“多个实例并发重建会造成无法接受的成本或数据矛盾”时，再引入 分布式锁。 缓存更新一律走 Cache Aside 异步删除，放弃复杂同步，靠重试和 TTL 兜底。 记住：锁是最后的手段，不是默认选项。 能靠最终一致和降级解决的，不要用强同步去惩罚高并发。