本地部署deepseek
在人工智能领域，大型语言模型（LLM）的应用越来越广泛，但许多用户希望能够在本地环境中部署和运行这些模型，以满足数据隐私、定制化需求或离线使用的场景。 DeepSeek-R1 是最近非常火爆的一个高性能的 AI 推理模型，专注于数学、代码和自然语言推理任务。Ollama 是一个强大的工具，可以帮助用户在本地轻松部署和管理大型语言模型 1. Ollama 简介Ollama 是一个开源的本地化大模型部署工具，旨在简化大型语言模型（LLM）的安装、运行和管理。它支持多种模型架构，并提供与 OpenAI 兼容的 API 接口，适合开发者和企业快速搭建私有化 AI 服务。 ollama官网直达 R1模型 Ollama 的主要特点包括： 轻量化部署：支持在本地设备上运行模型，无需依赖云端服务。多模型支持：兼容多种开源模型，如 LLaMA、DeepSeek 等。高效管理：提供命令行工具，方便用户下载、加载和切换模型。跨平台支持：支持 Windows、macOS 和 Linux 系统。 2. DeepSeek-R1 简介DeepSeek-R1 是由深度求索（DeepSeek）公司开发的高性能...
Hbase的写逻辑
1. Hbase写流程Hbase的数据写入流程可以分为三步： 第一步： 获取RegionServer Client 获取数据写入的 Region 所在的 RegionServer 第二步：请求写Hlog Hlog 存储在 HDFS，当 RegionServer 出现异常，需要使用 Hlog 来恢复数据。 第三步：请求写MemStore 请求写 MemStore,只有当写 Hlog 和写 MemStore 都成功了才算请求写入完成。MemStore 后续会逐渐刷到 HDFS 中。 2. MemStore刷盘为了提高 Hbase 的写入性能，当写请求写入 MemStore 后，不会立即刷盘。而是会等到一定的时候进行刷盘的操作。具体是哪些场景会触发刷盘的操作呢？总结成如下的几个场景： 全局内存控制 这个全局的参数是控制内存整体的使用情况，当所有 memstore 占整个 heap 的最大比例的时候，会触发刷盘的操作。这个参数是hbase.regionserver.global.memstore.upperLimit，默认为整个 heap 内存的...
Hbase的核心架构
Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组建组成。 1. ClientClient 包含了访问 Hbase 的接口，另外 Client 还维护了对应的 cache 来加速 Hbase 的访问，比如 cache 的.META.元数据的信息 2. ZookeeperHbase 通过 Zookeeper 来做 master 的高可用、RegionServer 的监控、元数据的入口以及集群配置的维护等工作。具体工作如下: ① 通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行，如果 master 异常，会通过竞争机制产生新的 master 提供服务 ② 通过 Zoopkeeper 来监控 RegionServer 的状态，当 RegionSevrer 有异常的时候，通过回调的形式通知 Master RegionServer 上下文的信息 ③ 通过 Zoopkeeper 存储元数据的统一入口地址。 3. Hmastermaster 节点的主要职责如下： ① 为 RegionServer...
Hbase介绍
1. 什么是HbaseHbase 是分布式、面向列的开源数据库（其实准确的说是面向列族）。HDFS 为 Hbase 提供可靠的底层数据存储服务，MapReduce 为 Hbase 提供高性能的计算能力，Zookeeper 为 Hbase 提供稳定服务和 Failover 机制，因此我们说 Hbase 是一个通过大量廉价的机器解决海量数据的高速存储和读取的分布式数据库解决方案。 2. 列式存储列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。 3. Hbase的核心概念3.1 Column Family 列族Column Family 又叫列族，Hbase 通过列族划分数据的存储，列族下面可以包含任意多的列，实现灵活的数据存取。Hbase 表的创建的时候就必须指定列族。就像关系型数据库创建的时候必须指定具体的列是一样的。Hbase 的列族不是越多越好，官方推荐的是列族最好小于或者等于 3。我们使用的场景一般是 1 个列族。 3.2 RowKey Rowkey 查询，Rowkey 范围扫描，全表扫描Rowkey 的概念和 mysql...
Kafka消费者设计
1. Consumer Group同一 Consumer Group 中的多个 Consumer 实例，不同时消费同一个 partition，等效于队列模式。partition 内消息是有序的，Consumer 通过 pull 方式消费消息。Kafka 不删除已消费的消息对于 partition，顺序读写磁盘数据，以时间复杂度 O(1)方式提供消息持久化能力。
Kafka生产者设计
1. 负载均衡 partition 会均衡分布到不同 broker 上 由于消息 topic 由多个 partition 组成，且 partition 会均衡分布到不同 broker 上，因此，为了有效利用 broker 集群的性能，提高消息的吞吐量，producer 可以通过随机或者 hash 等方式，将消息平均发送到多个 partition 上，以实现负载均衡。 2. 批量发送批量发送是提高消息吞吐量重要的方式，Producer 端可以在内存中合并多条消息后，以一次请求的方式发送了批量的消息给 broker，从而大大减少 broker 存储消息的 IO 操作次数。但也一定程度上影响了消息的实时性，相当于以时延代价，换取更好的吞吐量。 3. 压缩Producer 端可以通过 GZIP 或 Snappy 格式对消息集合进行压缩。Producer 端进行压缩之后，在Consumer 端需进行解压。压缩的好处就是减少传输的数据量，减轻对网络传输的压力，在对大数据处理上，瓶颈往往体现在网络上而不是 CPU（压缩和解压会耗掉部分 CPU 资源）。
Kafka介绍
1. Kafka相关的概念Kafka 是一种高吞吐量、分布式、基于发布/订阅的消息系统，最初由 LinkedIn 公司开发，使用Scala 语言编写，目前是 Apache 的开源项目。 broker：Kafka 服务器，负责消息存储和转发 topic：消息类别，Kafka 按照 topic 来分类消息 partition：topic 的分区，一个 topic 可以包含多个 partition，topic 消息保存在各个partition 上 offset：消息在日志中的位置，可以理解是消息在 partition 上的偏移量，也是代表该消息的唯一序号 Producer：消息生产者 Consumer：消息消费者 Consumer Group：消费者分组，每个 Consumer 必须属于一个 group Zookeeper：保存着集群 broker、topic、partition 等 meta 数据；另外，还负责 broker 故障发现，partition leader 选举，负载均衡等功能 2. Kafka...
Zookeeper的工作原理
Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式 当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了。 状态同步保证了 leader 和 server 具有相同的系统状态 一旦 leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server 加入 zookeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的followers 支持 广播模式需要保证 提议(proposal) 被按顺序处理，因此 zk 采用了递增的事务 id...
Zookeeper的投票机制
1. 选举过程每个 sever 首先给自己投票，然后用自己的选票和其他 sever 选票对比，权重大的胜出，使用权重较大的更新自身选票箱。具体选举过程如下： 每个 Server 启动以后都询问其它的 Server 它要投票给谁。对于其他 server 的询问，server 每次根据自己的状态都回复自己推荐的 leader 的 id 和上一次处理事务的 zxid（系统启动时每个 server 都会推荐自己） 收到所有 Server 回复以后，就计算出 zxid 最大的哪个 Server，并将这个 Server 相关信息设置成下一次要投票的 Server。 计算这过程中获得票数最多的的 sever 为获胜者，如果获胜者的票数超过半数，则改server 被选为 leader。否则，继续这个过程，直到 leader 被选举出来 leader 就会开始等待 server 连接 Follower 连接 leader，将最大的 zxid 发送给 leader Leader 根据 follower 的 zxid...
Zookeeper的ZAB协议
1. ZAB 协议在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息广播协议） 协议的事务编号 Zxid设计中，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的 ZXID，并从中读取epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。 事务编号 Zxid（事务请求 epoch + 计数器）,Zxid（Transaction id）类似于 RDBMS 中的事务 ID，用于标识一次更新操作的 Proposal（提议）ID。为了保证顺序性，该 zkid 必须单调递增。 1.2 epochepoch：可以理解为当前集群所处的年代或者周期，每个 leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加...