技术

组成对象 服务器 RADIUS服务器 接入策略：定义上网限速、VLAN、ACL 等统一授权模板 接入服务：绑定接入策略，勾选 Portal 无感知认证，开启账号与 MAC 自动绑定能力，是 MAC-trigger 总开关 接入用户：创建上网账号，绑定带无感知开关的接入服务，首次 Portal 登录后 iMC 记录账号 - MAC 对应关系 Portal服务器 配套 MAC 绑定服务器：对接 AC 侧 portal mac-trigger-server，接收 AC 上报终端 MAC，匹配已绑定账号后下发 DAE COA 报文实现免弹窗 NAS客户端（Network Access Server，网络接入服务器，这里通常是AC） RADIUS NAS 处理账号校验、计费、DAE 动态放行下线 Portal NAS 网页跳转、页面传参、会话心跳 挂载用户ip地址组 配置Portal 服务器 (iMC) 与 NAS (AC)之间的交互加密方式 PAP 两次握手 明文传输 CHAP 三次挑战握手 哈希校验 EAP 扩展认证 搭配iNode客户端 允许无感知认证 业务流量 为什么划分三个vlan，这是理解mac trigger流量路径的关键。 CAPWAP业务流量 为了让AP上线 用户上网业务流量 ap设置本地转发的情况 需要制作配置文件传输到ap上，放通ap端口的vlan200 ap设置集中转发的情况 无需放通ap端口vlan200，只需放通ac端口vlan200即可 如何识别需要重定向的流量、如何实现漫游、无感知认证。这些业务流量都单独走这个vlan 服务器认证流量 AC 交换机 iMC互通，专门用于nas和imc server之间的3a认证通信等

一、前言 & 场景痛点 在网络仿真学习场景中，很多用户会使用 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 异步） ...