掘金 & bilibili学习笔记

  1. Arthas

    Java监控诊断产品

    场景的弊端

    客户线上问题，应该如何复现，让客户再点一下吗？

    异常被吃掉，手足无措，看是哪个家伙写的，竟然是自己！

    排查别人线上的 bug，不仅代码还没看懂，还没一行日志，捏了一把汗！

    预发 debug，稍微时间长点，群里就怨声载道！

    加日志重新部署，半个小时就没了，问题还没有找到，头顶的灯却早已照亮了整层楼……

    线上机器不能 debug，也不能开 debug 端口，重新部署会不会破坏现场呢?

    怀疑入参有问题，怀疑合并代码有问题，怀疑没有部署成功，全是问号……

    一个问题排查一天，被 Diss 排查问题慢……

    使用的案例：

    1. 排查CPU起飞的问题

      1. 使用thread查看所有线程信息，同时会列出每个线程的CPU使用率

        img

      2. 使用命令thread 12 查看12号线程信息，可以看到该线程中使用CPU较高的方法和行数

        img

    2. dashboard 查看系统实时数据面板

    3. watch com.Arthas addHashSet ‘{params[0],returnObj}’ 查看入参和出参…

  2. 分布式锁

    分布式系统中的并发问题

    • 竟态条件

      img

      指多个进程 / 线程在执行顺序上产生了不确定性，从而导致程序的行为不可预测

      分布式系统中，多个节点同时访问共享资源，需要一个合理的同步机制

    • 数据不一致

      img

      分布式系统中由于数据的拆分和复制，数据的一致性会受到影响

      CAP 定理指出，在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）这三个属性不可能完全同时满足。因此，在设计分布式系统时，需要在一致性、可用性和分区容错性之间做出权衡，这可能导致数据不一致的情况发生。

    • 死锁

      img

      分布式系统中，多个节点可能同时竞争资源，类似多个进程竞争同一主机的资源；需要一个良好的协调机制

    基于数据库的分布式锁

    本质是在分布式集群外，抽出一台服务器负责管理锁，在此将管理的模式匹配到数据库中

    优缺点

    优点 缺点
    实现相对简单，不需要引入额外的组件。 性能相对较差，数据库的IO开销较大。
    可以使用数据库的事务机制确保数据的一致性。 容易产生死锁，需要谨慎设计。
    不适用于高并发场景，可能成为系统的瓶颈。

    基于缓存的分布式锁

    也是抽出一台服务器负责管理锁，在此将管理模式匹配到Redis

    命令：

    • SETNX（set if not exists） / 确定是没办法同时设置expire time，需要在下一个命令中设置 expire

    • set key value ex 10 nx / 更原子性

    优缺点

    优点 缺点
    性能较高，缓存系统通常在内存中操作，IO开销较小。 可能存在缓存失效和节点崩溃等问题，需要额外处理。
    可以使用缓存的原子操作确保获取锁的安全性。 需要依赖外部缓存系统，引入了系统的复杂性。
    适用于高并发场景，不易成为系统的瓶颈。

    其他注意点：

    1. 可重入 —— > value中还要存一个count

    2. 锁粒度的选择 —— >

    3. 超时时间的选择

    4. 解决redis单点问题 —— > RedLock

      思想：在多个Redis实例上创建相同的锁，使用SETNX获取锁。只有当大部分获取到锁才认为成功

  3. java新版本有价值的更新

    1. Local Variable Type Inference（局部变量类型推断） | JDK 10

      编码时不指定类型的情况下，编译时由值的类型推断出来

    2. switch语法糖增强 | JDK14

      1
      2
      3
      4
      5
      6
      7
      int flag = 1;
      switch(flag) {
          case 1,4 -> System.out.println("hello");
          case 2 -> System.out.println("world");
          case 3 -> System.out.println("hello world");
          default -> System.out.println("haha");
      }

      有点像lambda / js中箭头表达式 ；整体而言更像面向函数编程的思想

    3. Text blocks 文本块 | JDK 15

      传统文本换行需要 /n，新版本只需关注文本块中的内容

      image-20240506111919888

    4. record关键字

      替换Lombok

      但是很多类需要builder模式，二者并不兼容

    5. Sealed class 封闭类 | java 17

      允许将一个类 或 接口 的集成 / 实现 限制在一组有限的子类中

      例如：某个UserService接口只允许 UserServiceImpl实现，就需要用sealed将这个类表述为封闭类，同时使用permits关键字来定制可继承和实现的类有哪些

      实现 / 继承的类需要声明为final或者non-sealed

      1
      2
      public sealed interface UserService permits UserServiceImpl, UserServiceFinalImpl{
      }

    6. NullPointerException更多异常信息，能够更准确的定位

      image.png

  4. Nginx

    架构

    image.png

    特点：

    1. 事件驱动 & 异步非阻塞

      事件驱动：

      • 传统IO模型中，痛点在于用户线程往往需要等待缓冲区数据准备（无论是等文件系统还是网卡），导致一个线程只能处理一个请求

      • 事件驱动意味着主动权倒置：当缓冲区的数据准备好后再占用用户线程

        具体实现方式：

        1. 异步IO —— AIO

          • 当某个IO事件完毕后给用户线程发送一个事件通知

        2. IO多路复用

          • 一个线程检查多个连接的数据是否准备完毕，某个请求的数据完毕后，再通知用户线程执行后续代码【本质实现了异步IO，但并不是由文件系统 / 网卡发起通知，而是委托轮询的线程】

            无需异步，无需轮询，无需长连接，而是压榨一个线程

        事件驱动机制就是指当有读/写/连接事件就绪时 再去做读/写/接受连接这些事情，而不是一直在那里傻傻的等，也正应了他的名词： 【事件驱动！】，基于事件驱动思想设计的多路复用I/O（如select/poll，epoll），相对于传统I/O模型，达到了异步非阻塞的效果！

      Nginx使用IO多路复用

    2. 类似的Reactor模型

    3. Proxy Cache（服务器缓存）

      Nginx作为反向代理的第一关，可能会将服务器的响应数据存储在本地磁盘

      在缓存数据时，还运用零拷贝 & mmap技术使得copy性能大幅提升

    模块：

    image.png

    “高内聚 低耦合代表”

    常见应用场景：

    • 反向代理

    • 负载均衡

    • 缓存

    • 限流

      两种限流方式：

      • 按并发连接数量限流

        每个IP最大支持12个连接

      • 按请求速率限流（QPS）

        可能限制每秒同一ip最多一秒访问5次

    • 黑/白名单

    • 静态资源服务

    • 动静分离

    • 防盗链

    • 跨域

    • 高可用

    • …….

    核心功能参数调整全都内聚在nginx.conf中

    文件解读：

    • nginx.conf由一个一个指令块组成，用{}界定指令块

    • 分为：全局块，events块，http块，location块，upstream块

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      全局模块
      event模块
      http模块
          upstream模块

          server模块
              location块
              location块
              ....
          server模块
              location块
              location块
              ...
          ....

    压缩：

    目前大多数网站都在使用gzip传输HTML、CSS、JS等资源文件

  5. 比特币

    1. 2008年11月1日，中本聪《白皮书》– 比特币，一种点对点的电子现金系统

    2. 去中心化的电子记账系统

      传统记账系统由银行中心负责记账，区块链则将账本分布式的、公开的存储在多个节点上

    3. 为什么要记账？记账有奖励

      比特币

      • 中本聪在08年提出一种机制

        每十分钟将账目打包成一个区块，第一个四年每个打包的奖励是4个比特币，之后每四年奖励减半 | 其中，比特币的发行是由机制负责的，并没有中心机构

        如此一来，比特币总量大约2100万个，时间越往后奖励越少，表示比特币越珍贵

      • 奖励谁？ / 以谁为准？

        工作量证明POW —— 挖矿

        原理：

        1. 每个记账用户在准备将本地账本封装成区块前，手里有一个大字符串，内容是：前块的头部 + 本地账单 + 时间戳 + 个人信息 + 随机数

        2. 随机数由记账用户盲猜，目的是使得整个字符串的二次哈希结果满足要求

          • 要求：区块链机制会要求最后的哈希结果只有前n位是0才算是正确答案，而n的取值（difficulty）由机制决定，当前挖矿的算力越高，n越大（计算越难），算力越低，n越小（计算越简单）；目的是为了保证可以十分钟左右打包一个区块

          • 举例而言：

            假如共有10000台矿机，每台的算力是14T/s（等于1.4 × 10e13次/s），十分钟内能够计算8 × 10e19次，约等于2e66；所以为了在十分钟内大概有一次计算能够命中，n可取66，即要求二次哈希的前66位必须为0

  6. Web3

    1. Web1：【只读】

      Web内容是静态的，信息由机构聚合，例如YAHOO，搜狐，新浪

    2. Web2：【可读、可写】

      Web2的内容由用户动态生成，数据存储在中心化的服务器中

    3. Web3：【可拥有】

      使用区块链技术、智能合约、去中心化、不可篡改…

    学科要点：

    1. 密码学：密码学是区块链底层安全机制的保障

    2. 比特币：

    3. 以太坊：去中心化的全球计算机（区块链技术不仅用来记账，还能用于应用）

    4. 智能合约：以太坊上运行的程序

      开发者可以在以太坊上使用Solidity语言创建运行于EVM上的应用程序（智能合约）

      特点：

      • 去中心化

      • 代码即法律 | 无需第三方

      • 无需准入

      • 可组合

    5. 智能合约安全

    6. Web3应用——加密钱包

      在区块链上，通过加密钱包管理资产，由于没有中心化机构保障资产安全，只通过个人私钥 / 助记词保障资产归属

      谁拥有私钥，谁就拥有资产

      而公钥就是链上的地址 / 用户名

      Web3应用——DEFI

      去中心化金融：建立在区块链、智能合约平台上的金融类产品工具

      和传统金融相比，智能合约代替中心化银行

      Web3应用——NFT

      Web3应用——DAO

      去中心化自治组织：通过智能合约报纸运转的组织，与公司制相对

  7. 密码学基础

    1. 科尔霍夫原则

      对于一个密码学系统，应当仅有密钥是保密的，其余算法和一切参数都应该是公开的

      保密并不意味着数学上不可破解，而只需要现实中不可破解即可

    2. 古典加密算法（属于堆成加密）【凯撒密码、维吉尼亚密码】

    3. 现代对称加密算法

      缺点：双方必须事先共享密钥

    4. 非对称加密算法

掘金 & bilibili学习笔记
http://songlin.work/2025/04/20/掘金笔记/
作者
songlin
发布于
2025年4月20日
许可协议