cloud_fly blog

打开电源,BIOS或者UEFI(相比BIOS更新，BIOS磁盘大小限制是2TB，而UEFI没有磁盘大小限制。此外UEFI有更好的安全性和速度)固件会从非易失性内存(ROM)中加载，并执行POST开机自检 BIOS/UEFI检测连接到系统的设备，包括CPU、内存和存储设备 选择一个启动设备来启动操作系统。可以是硬盘、CD ROM或者网络服务器 BIOS/UEFI运行引导加载器(GRUB),它提供了一个选择操作系统或者内核功能的菜单 内核准备就绪后，切换到用户空间。内核启动systemd作为第一个用户进程作为init进程，负责管理进程和服务、探测所有硬件设备、挂载文件系统并运行桌面环境 系统启动时，systemd默认激活default.target单元，同时还会执行其他分析单元 系统运行一组脚本启动并配置环境 用户看到一个登录窗口，系统准备就绪

Git cheat sheet 让你不用再去记所有的 git 命令。 欢迎贡献内容、更新语法错误，也欢迎添加你母语版本的 Git cheat sheet。 Git Cheat Sheet 中文版索引 配置 配置文件 创建 本地修改 搜索 提交历史 移动/重命名 分支与标签 更新与发布 合并与重置 撤销 Git Flow 配置列出当前配置：1$ git config --list 列出 repository 配置：1$ git config --local --list 列出全局配置：1$ git config --global --list 列出系统配置：1$ git config --system --list 设置用户名：1$ git config --global user.name "[firstname lastname]" 设置用户邮箱：1$ git config --global user.email "[valid-email]" 设置 git 命令行输出为彩色：1$ git config...

样例： 在秒杀抢购优惠券环节，key是用户id+优惠券id，value是后端机器id 在多阶段异步流任务框架中，key是任务id，value是后端机器id key是用户id是让一个用户在同一时间内只能做一次访问数据库操作 key是优惠券id是让一个优惠券在同一时间只能被访问一次 value永远都是后端机器id，表示锁的持有者 总结： 如果你要保证一个任务在同一时刻只被处理一次，那么key就是这个任务id 如果你要保证一个优惠券在同一时刻只被一个人抢购一次，那么这个key就是用户id+优惠券id 等价于数学上取交集 value永远都是后端机器id，表示锁的持有者

Kafka顺序写前面已经提到Kafka写入数据其实是添加到每个Partition的末端，也就是写入对应的磁盘文件，设计简单高效 下面介绍具体的机制 Kafka兼顾了高性能和低复杂度，采用顺序写机制（直接顺序写入磁盘），将写入模式设计成了顺序写，这里要注意一点，写磁盘不一定是直接刷盘的，只是说提交给了操作系统，这里还是有丢失数据的可能性，只是相对于先写Kafka应用程序内存，已经减少了一个可能遗失的环节 顺序写优势： 高效的磁盘利用：顺序写性能优于随机写 简单的存储管理： 顺序写入简化了日志段的管理和消息的追加操作 日志文件按顺序组织，便于快速查找和读取消息 可靠性和一致性： 顺序写入有助于保证消息的可靠性，因为一旦写入日志文件（.log），消息就不会丢失 消费者可以通过偏移量准确地读取数据，确保消息处理的顺序和一致性 为什么顺序写这么快？ 因为磁盘寻址是需要转动的，随机写入每一次寻址都要机械活动，很花费时间。而顺序写入只需要一次寻址 Kafka页缓存Kafka利用操作系统自带的Page cache，来实现一定程序顺序读写内存 Page...

Replica、Leader和Follower Replica： Kafka集群中的一个副本，可以是Leader副本或者是Follow副本中的一个。每个分区都有多个副本，其中一个副本是Leader副本，其余是Follow副本。每个副本都保存了分区的完整数据，用于保证数据的可靠性和高可用性 Leader：负责该分区的所有读写请求，也是唯一可以向分区写入数据的副本，它将写入的数据同步到所有的Follow副本 Follow：不能直接向分区写入数据，只能从Leader副本中复制数据，并同步到本地。当Leader副本挂掉的时候，会从所有Follow副本中选择一个作为新的Leader副本 AR、ISR、OSR AR（Assigned Replica）：分区的所有副本，包括Leader副本和所有Follow副本 ISR（In-Sync...

Kafka什么情况下会出现消息丢失的情况 消息生产时如果设置的acks不是全部副本，那么如果follower副本在未完成同步之前，leader副本挂掉了，就会导致消息丢失。 存储时如果没有多副本备份，消息也可能会丢失 消费时如果没有确认消费成功再提交offset，而这时候消费者又挂掉了，消息同样会丢失 Kafka如何保证消息不丢失 设置生产者配置参数acks =...

...

介绍一下生产消息的流程 构建消息，将需要发送的内容打包成一个消息结构 序列化消息为二进制结构，以在网络中传播 进行分区选择，计算需要发送到哪个partition，发送消息到该partition对应的Broker Kafka的ACK的三种机制生产者的写入策略： acks = 0：生成者在发送消息后不会等待来自服务器的确认，所以生产者是不知道消息是否成功，也就无法去重试。最不可靠但是性能最好 acks = 1：生产者在发送消息后会等待主节点的确认，但不会等待所有副本的确认。相对可靠，性能比较高 acks =...

Kafka的大致框架是什么样 Kafka分为三层：生产者（Producer）、中转者（Server）、消费者（Consumer） 生产者负责发送消息，服务端负责存储消息，消费者负责拉取消息 其中服务端是由多个Broker节点组成，我们常说的主题Topic在Broker节点上。当然，Topic是一个逻辑概念，实际物理存储是主题分片，也就是Partition 如何获取topic主题的列表 Kafka提供了获取主题列表的接口，可以通过kafka-topic.sh这个工具获取，如果要在业务中获取，主流语言比如Java、Golang都支持，都可以直接调用KafkaAdminClient这个接口来获取 kafka-topics.sh 脚本主要负责 topic 相关的操作。它的具体实现是通过 kafka-run-class 来调用 TopicCommand 类，并根据参数执行指定的功能 通过kafka-topics.sh获取： 1./kafka-topics.sh --list --bootstrap-server...

消息队列常见应用常见有哪些 系统解耦：在重要操作完成之后，发送消息到Kafka，由别的服务系统来完成 流量削峰：缓存短时间内高流量带来的压力 异步处理：把一个消息放入到Kafka中，不立即处理，需要的时候再来处理 消息分发：一条消息发送给多个服务 Kafka优点 高性能 高可靠 支持分片水平扩展 被广泛使用 什么情况需要解耦比如模块A发送消息给模块B，模块B发送短信给客户，A不需要得到回应，对于A而言只需要将消息发送给B，让B去处理即可 什么情况需要削峰比如B一下子收到100条信息可能会挂掉，这时候需要将消息先发送给消息队列，然后B再根据自己的消费能力去消费 什么情况需要分发消息比如信息更新场景，某个用户更新了，而B、C、D都缓存了这个消息。只要B、C、D订阅了这个主题，也都会更新 为什么选择Kafka作为消息队列 我们的项目对性能和可靠性有要求 性能要有500QPS，这里Kafka和RocketMQ都远远够用 可靠性要有多副本机制，这点Kafka和RocketMQ也都OK 其他功能不是我们项目的核心要点 Kafka是我们团队成熟的技术栈