https://sirius2alpha.github.io/categories/tools/ Recent content in Tools on Sirius' Blog https://sirius2alpha.github.io/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E https://sirius2alpha.github.io/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E Hugo -- 0.127.0 en-us Fri, 16 May 2025 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/thunderbird-icloud/ Fri, 16 May 2025 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/thunderbird-icloud/ 记录在Thunderbird上同步icloud日历与联系人 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/latex_resume/ Mon, 18 Mar 2024 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/latex_resume/ 这篇文章记录了简单的LaTex语法，以及我修改模板的过程 https://sirius2alpha.github.io/posts/notes/3-resources/%E9%97%AE%E9%A2%98%E8%AE%B0%E5%BD%95/problem-clash_for_linux/ Mon, 08 Jan 2024 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E9%97%AE%E9%A2%98%E8%AE%B0%E5%BD%95/problem-clash_for_linux/ 记录配置clash的过程 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/git-use/ Sun, 27 Aug 2023 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/git-use/ 记录使用git的常用命令，以及对git的工作模式进行简单讲解 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/git-pr/ Sun, 27 Aug 2023 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/git-pr/ 关于如何在终端中合并团队成员的PR https://sirius2alpha.github.io/posts/notes/2-areas/%E6%8A%80%E6%9C%AF%E6%A0%88/kafkainfo/ Thu, 24 Aug 2023 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/2-areas/%E6%8A%80%E6%9C%AF%E6%A0%88/kafkainfo/ 消息队列的特性 卡夫卡(Kafka)作为消息队列的一种，拥有异步、削峰、解耦三种特性，并依靠这些特性，他经常在搜索、直播、订单和支付服务。 **异步：**不同于同步通信的需要等待接收方响应，异步通信的发送方在发送消息到消息队列后，不等待接收方响应，而是继续进行其他操作。接收方仅需要从消息队列中拉取消息即可。 异步操作减少了流程长度，提高消息的吞吐量和效率。 **削峰：**对于突发的消息高峰，消息队列起到了存储请求的作用，使后台能以稳定的速率处理消息，从而减少了服务器的高峰负担，提高系统的稳定性。 解耦：解耦合即降低各个组件之间的依赖。使用消息队列，发送者和接收者各种把自己的消息发送给消息队列，从而实现解耦，方便各自开发部署，避免一方接口发生错误而影响多方，实现错误隔离。 卡夫卡的基本概念 **逻辑队列(Topic)：**可以建立不同的逻辑队列，存储于物理集群中。 **物理集群(Cluster)：**可建立多个逻辑队列。 **生产者(Producer)：**发送消息到逻辑队列。 **消费者(Consumer)&消费者组(Consumer Group)：**消费逻辑队列内的消息，各个消费者组互不干扰。 **Offset：**记录消息在有序序列Partition中的相对位置，每个Topic可分为多个Partition。Offset是消息的唯一ID，并在序列中严格递增。搜索Offset采用二分查找找到小于目标Offset的最大索引位置（时间戳索引类似）。 **Replica：**相当于副本，保证集群中节点上的 Partition 数据不因故障丢失。每个Partition有一个Replica-Leader，用于写入，同时拥有多个Follower用于记录Leader。如果Follower数据与Leader差距过大则踢出ISR。Replica又以log日志文件存储。 卡夫卡的消费模式 卡夫卡消息队列有两种最常见的消费模式。 **一对一：**生产者将消息发送到消息队列后，由消费者从队列中拉取并消费，然后信息会被删除。 一对多：即发布-订阅模式。生产者将消息发送到逻辑队列(Topic)（逻辑队列存储在Cluster物理集群中），可以被多个消费者订阅，从而实现每个消费者独立从该主题中拉取消息，值得注意的是该模式下消息并不会在消费后立刻删除，而是会在删除前保留一段时间。 然而在实际业务中，这两种消费模式并不能覆盖所有常业务场景，因此也会衍生出如竞争消费和优先级消费等高级模式。 卡夫卡消息分配 **手动分配：**通过手动分配完成哪个consumer消费哪个Partition。缺点是当Consumer节点故障后，Partition数据流受影响；当出现新的Consumer，需要重新分配Partition。 **Rebalance：**通过设立Coordinator，自动识别故障的consumer节点或新增的consumer，实现自动分配。Consumer端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。 提高卡夫卡吞吐量和稳定性的方法 **Producer：**批量发送（降低io次数）、数据压缩（降低带宽流量）。 **Broker：**顺序写（提高吸入速度），消息索引，零拷贝。 **Consumer：**Rebalance分配。 卡夫卡的缺点 **重启操作：**重启broker后，Leader切换。与此同时数据仍在写入，导致重启的broker和当前的Leader数据产生差异，需要重新追赶后才能回切（由于其他broker也有可能需要重启），导致需要大量时间。 **替换、扩容、缩容操作：**替换与重启操作类似，不过由于是重新写入，所以需要的时间更多。扩容和缩容都需要进行复制操作，因此也需要大量时间。 **负载不均衡问题：**为降低某个Partition的IO写入而进行迁移，但同时也会引入新的IO负载，陷入恶性循环，需要复杂的解决方案。 缺点总结： 卡夫卡运维成本高。 负载不均衡问题严重。 没有缓存，依赖页缓存Page Cache。 Controller、Coordinator和Broker在同一进程中，IO性能下降。 https://sirius2alpha.github.io/posts/notes/2-areas/%E6%8A%80%E6%9C%AF%E6%A0%88/objectstore/ Wed, 23 Aug 2023 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/2-areas/%E6%8A%80%E6%9C%AF%E6%A0%88/objectstore/ 在做短视频项目的时候，我总是有个疑问：用户上传的视频我要存储在哪里呢？作为开发小白，目前只知道要存放数据就到DB里面去，那我想“那我的视频文件也要存储到MySQL里面去嘛？”emm，这的确是一个大难题，不过在互联网技术发达的今天，感谢各大论坛的支持，让我了解到了视频、图像这类非结构化数据最好是对象存储。 在此，你一定有一些疑惑： 为什么视频不用mysql这类数据库进行存储呢？ 对象存储是什么，使用它存储非结构化数据有什么好处呢？ 为什么不用MySQL存储非结构化数据？ 首先哈，mysql人家本来就是用来存储结构化数据的，视频文件是一种非结构化数据。 结构化数据/非结构化数据/半结构化数据 结构化数据： 结构化数据是以清晰、预定义格式存储的数据。它通常以表格、数据库或电子表格的形式存在，其中每一列都有明确的数据类型和定义，每一行代表一个记录。结构化数据非常适合使用关系型数据库管理系统（RDBMS）来存储和管理，因为数据的组织方式已经被预先定义好。例如，存储在数据库中的订单信息、员工工资表以及销售数据都属于结构化数据的示例。 非结构化数据： 非结构化数据则没有固定的格式，它可能包含不同类型的信息，如文本、图像、音频、视频等。这种数据类型通常不适合传统的关系型数据库，因为它们缺乏统一的结构。非结构化数据的处理相对更为复杂，需要使用特定的技术和工具，如自然语言处理（NLP）技术用于处理文本数据，计算机视觉技术用于处理图像数据等。社交媒体帖子、电子邮件内容、图像文件以及语音记录都属于非结构化数据的例子。 半结构化数据： 半结构化数据可能具有一定的格式，但不像完全结构化数据那样严格。常见的半结构化数据格式包括XML（可扩展标记语言）和JSON（JavaScript对象表示法）。这些数据通常具有一些层次结构，但字段可能不像传统数据库表中的列那样明确定义。 MySQL是一种关系型数据库管理系统，通常用于存储和管理结构化数据，如文本、数字、日期等。虽然MySQL可以存储二进制数据，但它并不是设计用来直接存储大量大文件（如视频文件）的最佳工具。 以下是为什么通常不使用MySQL存储视频文件的一些原因： 性能问题：MySQL的查询引擎是设计用来处理字符串、数值和日期等类型的数据的，对于大文件的存储和检索并不是最有效的。当你存储大量大文件时，可能会导致数据库性能下降，尤其是当你需要从数据库中检索这些文件时。 存储效率：数据库通常使用磁盘空间来存储数据，而文件系统（如NFS、HDFS等）则更高效地存储大文件。使用数据库来存储大文件可能会导致不必要的磁盘空间浪费。 文件操作：视频文件通常需要进行一些文件级别的操作，如复制、移动、删除等。这些操作通常比数据级别的操作更消耗资源。如果这些操作在数据库中进行，可能会导致性能问题。 扩展性：当你的视频库变得非常大时，你可能需要扩展你的存储系统。数据库的扩展性通常比文件系统要复杂得多。 因此，对于存储和管理视频文件，通常建议使用专门的文件存储系统，如NFS、HDFS、S3等。这些系统更高效地处理大文件，并且通常提供更好的扩展性和更好的性能。如果你需要从你的视频文件中检索信息，你可以将这些信息存储在关系型数据库中，并使用数据库的功能来查询和管理这些信息。 关于对象存储 对象存储是一种用于存储和管理大规模非结构化数据的存储架构。与传统的文件系统或块存储不同，对象存储将数据存储为"对象"，每个对象都包含数据本身以及与之相关的元数据（如文件名、创建日期、数据类型等）。这些对象被分布式地存储在多个服务器上，并通过唯一的标识符进行访问。 对象存储的主要特点包括： 扩展性： 对象存储设计用于应对海量数据的存储需求，可以轻松地扩展以适应不断增长的数据量，而无需大规模的基础架构变更。 分布式架构： 对象存储系统将数据分布在多个服务器上，提高了数据的可靠性和冗余性。即使某个服务器出现故障，数据仍然可以从其他服务器中恢复。 元数据： 每个对象都有丰富的元数据，这些元数据描述了对象的各种属性，包括文件名、大小、创建日期、数据类型等。这些元数据使得数据管理更加灵活和智能。 适应非结构化数据： 对象存储适用于存储各种类型的非结构化数据，如图像、音频、视频、日志文件、备份等。它不强制要求数据遵循特定的结构，因此非常适用于大多数现代应用生成的多样化数据。 数据访问和检索： 对象存储通常提供强大的数据访问和检索功能。您可以使用对象标识符进行数据检索，而不需要像传统文件系统那样的层次化文件路径。 云集成： 许多云平台提供对象存储服务，使得在云环境中存储和管理数据变得更加简单和经济。 三种存储形态 块存储（Block Storage） 块存储将数据分割成固定大小的块，通常以扇区（一般为512字节或更大）为单位。这些块可以被单独管理，读取和写入。块存储通常在底层使用了虚拟化技术，将块映射到物理存储设备上。块存储适用于需要随机读写的应用，如操作系统的磁盘，数据库，虚拟机镜像等。 主要特点： 低延迟的读写操作。 支持随机读写访问。 通常用于需要高性能、低延迟和数据管理控制的应用。 文件存储（File Storage） 文件存储模式以文件为单位进行存储和管理。文件存储模式通常使用网络协议（如NFS或SMB）提供共享文件系统，使多台计算机能够共享相同的文件。这种模式适用于需要多台计算机访问相同文件的应用，如共享文件夹、办公文档、媒体文件等。 主要特点： 以文件为单位进行管理和访问。 适用于多台计算机之间的文件共享和协作。 不适合大规模、高并发的访问。 对象存储（Object Storage） 对象存储是一种将数据以对象形式进行存储的方法。每个对象都包含数据本身、元数据（如文件名、创建日期等）以及一个唯一的标识符。对象存储通常在分布式环境中工作，可以自动扩展以适应大规模的数据。它适用于大规模的非结构化数据，如图像、音频、视频文件，以及需要长期保留和高可用性的数据。 主要特点： 以对象为单位存储，每个对象都有唯一的标识符。 可以存储海量非结构化数据。 高可扩展性和可用性。 适合数据归档、备份和云存储等场景。 区别 块存储以固定大小的块为单位进行读写，适用于随机读写的应用； 文件存储以文件为单位共享，适用于多台计算机之间的文件共享和协作； 对象存储以对象为单位存储，适用于海量非结构化数据的存储。 块存储和文件存储通常在操作系统级别进行管理，而对象存储在应用程序级别进行管理。 对象存储通常具有更高的可扩展性和冗余性，适合大规模和长期数据存储。 块存储和文件存储在访问控制和数据管理方面更加灵活，而对象存储强调数据的元数据和可扩展性。 常见的云平台的对象对象服务 腾讯云：对象存储 COS 阿里云：对象存储 OSS 火山引擎：对象存储TOS Azure：Azure Blob 存储 国内的各大云厂商的对象存储服务文档对他们的产品都介绍的挺详细的，我看了火山引擎TOS和Azure的存储服务，Azure的冗余服务在TOS中叫做多AZ冗余服务，大同小异，没有实际自己用过。国内云厂商对于学生的支持感觉还是不够，想要用还是得要自己掏钱，希望未来各大厂商还是能支持以下学生发展，积累一些企业口碑。 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/clash-for-linux/ Thu, 13 Apr 2023 00:00:00 +0000 https://sirius2alpha.github.io/posts/notes/3-resources/%E5%B7%A5%E5%85%B7%E9%85%8D%E7%BD%AE/clash-for-linux/ 记录从cfw换到clash-for-linux