分布式ID服务实践

news2024/11/27 12:48:12

背景

分布式场景下需要一个全局 ID 来标识唯一性，比如在单数据库时通过表唯一主键即可实现唯一 ID，分库分表时就需要全局唯一 ID。

业务对唯一 ID 的要求如下：

  • 全局唯一性

不能出现重复的 ID 号，既然是唯一标识，这是最基本的要求。

  • 趋势递增、单调递增

保证下一个 ID 一定大于上一个 ID。

  • 信息安全

如果 ID 是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定 URL 即可；
如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要 ID 无规则、不规则。

同时除了对 ID 号码自身的要求，业务还对 ID 号生成系统的可用性要求极高。想象一下，如果 ID 生成系统不稳定，大量依赖 ID 生成系统，比如订单生成等关键动作都无法执行。所以一个 ID 生成系统还需要做到平均延迟和 TP999 延迟都要尽可能低。最好能达到可用性 5 个 9、高 QPS。

方案

UUID

UUID（Universally Unique Identifier）的标准型式包含 32 个 16 进制数字，以连字号分为五段，形式为 8-4-4-4-12 的 36 个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有 5 种方式生成 UUID，详情见 IETF 发布的 UUID 规范 A Universally Unique IDentifier (UUID) URN Namespace。

优点：

  • 性能非常高：本地生成，没有网络消耗。

缺点：

  • 不易于存储：UUID 太长，16 字节 128 位，通常以 36 长度的字符串表示，很多场景不适用。
  • 信息不安全：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
  • ID 作为主键时在特定的环境会存在一些问题，比如做 DB 主键的场景下，UUID 就非常不适用：

1、MySQL 官方有明确的建议主键要尽量越短越好[4]，36 个字符长度的 UUID 不符合要求。
2、对 MySQL 索引不利：如果作为数据库主键，在 InnoDB 引擎下，UUID 的无序性可能会引起数据位置频繁变动，严重影响性能。在 MySQL InnoDB 引擎中使用的是聚集索引，由于多数 RDBMS 使用 B-tree 的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。

可以直接使用 jdk 自带的 UUID，原始生成的是带中划线的，如果不需要，可自行去除：

public class UUIDTest {
    public static void main(String[] args) {
        String uuid = UUID.randomUUID().toString();
        System.out.println(uuid);
        uuid = uuid.replaceAll("-", "");
        System.out.println(uuid);
        /**
         * f5d728aa-5c07-4fb5-bf58-18c232d2fae8
         * f5d728aa5c074fb5bf5818c232d2fae8
         */
    }
}

雪花算法

这种方案大致来说是一种以划分命名空间（UUID 也算，由于比较常见，所以单独分析）来生成 ID 的一种算法，Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 把 64-bit 分别划分成多段，分开来标示机器、时间等，比如在 snowflake 中的 64-bit 分别表示如下图所示：
image.png
第 0 位：符号位（标识正负），始终为 0，没有用，不用管。
第 1~41 位：一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约 69 年）。
第 42~52 位：一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整），这样就可以区分不同集群/机房的节点，这样就可以表示 32 个 IDC，每个 IDC 下可以有 32 台机器。
第 53~64 位：一共 12 位，用来表示序列号。 序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096)，也就是说单台机器每毫秒最多可以生成 4096 个 唯一 ID。
理论上 snowflake 方案的 QPS 约为 409.6w/s，这种分配方式可以保证在任何一个 IDC 的任何一台机器在任意毫秒内生成的 ID 都是不同的。
有很多基于 Snowflake 算法的开源实现比如美团的 Leaf、百度的 UidGenerator（自 18 年后，UidGenerator 就基本没有再维护了，[https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md](https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md))），并且这些开源实现对原有的 Snowflake 算法进行了优化。在实际项目中，我们一般也会对 Snowflake 算法进行改造，最常见的就是在算法生成的 ID 中加入业务类型信息。

优点：

  • 毫秒数在高位，自增序列在低位，整个 ID 都是趋势递增的。
  • 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成 ID 的性能也是非常高的。
  • 可以根据自身业务特性分配 bit 位，非常灵活。

缺点：

  • 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。

当然，在我们自己的项目如果不想自行实现唯一性 ID，还可以利用外部中间件，比如 Mongdb objectID，它也可以算作是和 snowflake 类似方法，通过“时间+机器码+pid+inc”共 12 个字节，通过 4+3+2+3 的方式最终标识成一个 24 长度的十六进制字符。
其次 Seata 内置了一个分布式 UUID 生成器，用于辅助生成全局事务 ID 和分支事务 ID，我们同样可以拿来使用，完整类名为：io.seata.common.util.IdWorker。

MYSQL

1） 创建一个数据库表

CREATE TABLE `sequence_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `stub` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

stub 字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。
2）通过 replace into 来插入数据

BEGIN;
REPLACE INTO sequence_id (stub) VALUES ('stub');
SELECT LAST_INSERT_ID();
COMMIT;

插入数据这里，我们没有使用 insert into 而是使用 replace into 来插入数据。replace 是 insert 的增强版，replace into 首先尝试插入数据到表中，如果发现表中已经有此行数据（根据主键或者唯一索引判断）则先删除此行数据，然后插入新的数据。否则，直接插入新数据。重复插入失败时是会生成新的 ID 的。

优点：

  • 非常简单，利用现有数据库系统的功能实现，成本小，有 DBA 专业维护。ID 号单调自增，存储消耗空间小。

缺点：

  • 支持的并发量不大、存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）
  • ID 没有具体业务含义
  • 安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！ ）
  • 每次获取 ID 都要访问一次数据库（增加了对数据库的压力，获取速度也慢）

对于 MySQL 性能问题，可用如下方案解决：在分布式系统中我们可以多部署几台机器，每台机器设置不同的初始值，且步长和机器数相等。比如有两台机器。设置步长 step 为 2，TicketServer1 的初始值为 1（1，3，5，7，9，11…）、TicketServer2 的初始值为 2（2，4，6，8，10…）。这是 Flickr（雅虎旗下图片分享网站）团队在 2010 年撰文介绍的一种主键生成策略（Ticket Servers: Distributed Unique Primary Keys on the Cheap ）。为了实现上述方案分别设置两台机器对应的参数，TicketServer1 从 1 开始发号，TicketServer2 从 2 开始发号，两台机器每次发号之后都递增 2。
假设我们要部署 N 台机器，步长需设置为 N，每台的初始值依次为 0,1,2…N-1。
这种架构貌似能够满足性能的需求，但有以下几个缺点：
系统水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做？假设现在只有一台机器发号是 1，2，3，4，5（步长是 1），这个时候需要扩容机器一台。可以这样做：把第二台机器的初始值设置得比第一台超过很多，比如 140（假设在扩容时间之内第一台不可能发到 140），同时设置步长为 2，那么这台机器下发的号码都是 140 以后的偶数。然后摘掉第一台，把 ID 值保留为奇数，比如 7，然后修改第一台的步长为 2。让它符合我们定义的号段标准，对于这个例子来说就是让第一台以后只能产生奇数。扩容方案看起来复杂吗？貌似还好，现在想象一下如果我们线上有 100 台机器，这个时候要扩容该怎么做？简直是噩梦。所以系统水平扩展方案复杂难以实现。
ID 没有了单调递增的特性，只能趋势递增，这个缺点对于一般业务需求不是很重要，可以容忍。
数据库压力还是很大，每次获取 ID 都得读写一次数据库，只能靠堆机器来提高性能。

Redis

通过 Redis 的 incr 命令即可实现对 id 原子顺序递增，例如：

127.0.0.1:6379> incr sequence_id_biz_type
(integer) 2

为了提高可用性和并发，我们可以使用 Redis Cluster。
除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。很明显，Redis 方案性能很好并且生成的 ID 是有序递增的。
不过，我们也知道，即使 Redis 开启了持久化，不管是快照（snapshotting，RDB）、只追加文件（append-only file, AOF）还是 RDB 和 AOF 的混合持久化依然存在着丢失数据的可能，那就意味着产生的 ID 存在着重复的概率。

美团 Leaf

Leaf 这个名字是来自德国哲学家、数学家莱布尼茨的一句话： There are no two identical leaves in the world（世界上没有两片相同的树叶）。
Leaf 分别在 MySQL 和雪花上做了相应的优化，实现了 Leaf-segment 和 Leaf-snowflake 方案。

Leaf-segment

Leaf-segment 方案，在使用数据库的方案上，做了如下改变：
原 MySQL 方案每次获取 ID 都得读写一次数据库，造成数据库压力大。改为批量获取，每次获取一个 segment（step 决定大小）号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。
各个业务不同的发号需求用 biz_tag 字段来区分，每个 biz_tag 的 ID 获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对 biz_tag 分库分表就行。
数据库表设计如下：
image.png
重要字段说明：
biz_tag：用来区分业务；
max_id：表示该 biz_tag 目前所被分配的 ID 号段的最大值；
step：表示每次分配的号段长度。
原来获取 ID 每次都需要写数据库，现在只需要把 step 设置得足够大，比如 1000。那么只有当 1000 个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从 1 减小到了1/step。
例如现在有 3 台机器，每台机器各取 1000 个，很明显在第一台 Leaf 机器上是 1~1000 的号段，当这个号段用完时，会去加载另一个长度为 step=1000 的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是3001~4000。同时数据库对应的 biz_tag 这条数据的 max_id 会从 3000 被更新成4000，更新号段的 SQL 语句如下：

Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit

优点：

  • Leaf 服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
  • ID 号码是趋势递增的 8byte 的 64 位数字，满足上述数据库存储的主键要求。
  • 容灾性高：Leaf 服务内部有号段缓存，即使 DB 宕机，短时间内 Leaf 仍能正常对外提供服务。可以自定义 max_id 的大小，非常方便业务从原有的 ID 方式上迁移过来。

缺点：

  • ID 号码不够随机，能够泄露发号数量的信息，不太安全。
  • TP999 数据波动大，当号段使用完之后还是会在获取新号段时在更新数据库的 I/O 依然会存在着等待，tg999 数据会出现偶尔的尖刺。
  • DB 宕机会造成整个系统不可用。

双 buffer 优化：
对于第二个缺点，Leaf-segment 做了一些优化，简单的说就是：
Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的 ID 下发时间取决于下一次从 DB 取回号段的时间，并且在这期间进来的请求也会因为 DB 号段没有取回来，导致线程阻塞。如果请求 DB 的网络和 DB 的性能稳定，这种情况对系统的影响是不大的，但是假如取 DB 的时候网络发生抖动，或者 DB 发生慢查询就会导致整个系统的响应时间变慢。
为此，希望 DB 取号段的过程能够做到无阻塞，不需要在 DB 取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的 TP999 指标。
采用双 buffer 的方式，Leaf 服务内部有两个号段缓存区 segment。当前号段已下发 10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前 segment 接着下发，循环往复。
通常推荐 segment 长度设置为服务高峰期发号 QPS 的 600 倍（10 分钟），这样即使 DB 宕机，Leaf 仍能持续发号 10-20 分钟不受影响。
每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。

Leaf 高可用容灾：
对于第三点“DB 可用性”问题，可以采用一主两从的方式，同时分机房部署，Master 和 Slave 之间采用半同步方式同步数据。美团内部使用了奇虎 360 的 Atlas 数据库中间件（已开源，改名为 DBProxy）做主从切换。当然这种方案在一些情况会退化成异步模式，甚至在非常极端情况下仍然会造成数据不一致的情况，但是出现的概率非常小。如果要保证 100% 的数据强一致，可以选择使用“类 Paxos算法”实现的强一致 MySQL 方案，如 MySQL 5.7 中的 MySQL Group Replication。但是运维成本和精力都会相应的增加，根据实际情况选型即可。

Leaf-snowflake

Leaf-segment 方案可以生成趋势递增的 ID，同时 ID 号是可计算的，不适用于订单 ID 生成场景，比如竞对在两天中午 12 点分别下单，通过订单 id 号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，美团提供了 Leaf-snowflake 方案。
Leaf-snowflake 方案完全沿用 snowflake 方案的 bit 位设计，即是“1+41+10+12”的方式组装 ID 号。对于 workerID 的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf 服务规模较大，动手配置成本太高。所以使用 Zookeeper 持久顺序节点的特性自动对 snowflake 节点配置 wokerID。Leaf-snowflake 是按照下面几个步骤启动的：
启动 Leaf-snowflake 服务，连接 Zookeeper，在 leaf_forever 父节点下检查自己是否已经注册过（是否有该顺序子节点）。
如果有注册过直接取回自己的 workerID（zk 顺序节点生成的 int 类型 ID 号），启动服务。
如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的 workerID 号，启动服务。

弱依赖 ZooKeeper：
除了每次会去 ZK 拿数据以外，也会在本机文件系统上缓存一个 workerID 文件。当 ZooKeeper 出现问题，恰好机器出现问题需要重启时，能保证服务能够正常启动。这样做到了对三方组件的弱依赖。

解决时钟问题：
因为这种方案依赖时间，如果机器的时钟发生了回拨，那么就会有可能生成重复的 ID 号，需要解决时钟回退的问题。
首先在启动时，服务会进行检查：
1、新节点通过检查综合对比其余 Leaf 节点的系统时间来判断自身系统时间是否准确，具体做法是取所有运行中的 Leaf-snowflake 节点的服务 IP:Port，然后通过 RPC 请求得到所有节点的系统时间，计算 sum(time)/nodeSize，然后看本机时间与这个平均值是否在阈值之内来确定当前系统时间是否准确，准确正常启动服务，不准确认为本机系统时间发生大步长偏移，启动失败并报警。
2、在 ZooKeeper 中登记过的老节点，同样会比较自身系统时间和 ZooKeeper 上本节点曾经的记录时间以及所有运行中的 Leaf-snowflake 节点的时间，不准确同样启动失败并报警。
另外，在运行过程中，每隔一段时间节点都会上报自身系统时间写入 ZooKeeper 。
在服务运行过程中，机器的 NTP 同步也会造成秒级别的回退，由于强依赖时钟，对时间的要求比较敏感，美团建议有三种解决方案，一是可以直接关闭 NTP 同步；二是在时钟回拨的时候直接不提供服务直接返回 ERROR_CODE，等时钟追上即可，三是做一层重试，然后上报报警系统，更或者是发现有时钟回拨之后自动摘除本身节点并报警。
从美团的实际运行情况来看，在 2017 年闰秒出现那一次出现过部分机器回拨，由于 Leaf-snowflake 的策略保证，成功避免了对业务造成的影响。

美团 Leaf 现状：
Leaf 在美团点评公司内部服务包含金融、支付交易、餐饮、外卖、酒店旅游、猫眼电影等众多业务线。目前 Leaf 的性能在 4C8G 的机器上 QPS 能压测到近 5万/s，TP999 1ms，已经能够满足大部分的业务的需求。每天提供亿数量级的调用量。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1286941.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

CGAL的周期三角剖分（相关信息较少）

CGAL的周期三角剖分（相关信息较少）

CGAL的周期二维三角剖分类旨在表示二维平面上的一组点的三角剖分。该三角剖分形成其计算空间的分区。它是一个单纯复体&#xff0c;即它包含任何k-单纯形的所有关联j-单纯形&#xff08;j<k&#xff09;&#xff0c;并且两个k-单纯形要么不重叠&#xff0c;要么共享一个公共…
阅读更多...
数据结构与算法-D2D3线性表之顺序表

数据结构与算法-D2D3线性表之顺序表

线性表&#xff1a;包含若干数据元素的一个线性序列&#xff0c;特征如下&#xff1a; 1&#xff09;对非空表&#xff0c;a0是表头&#xff0c;无前驱&#xff1b; 2&#xff09;an-1是表尾&#xff0c;无后继&#xff1b; 3&#xff09;其他元素仅且仅有一个前驱&#xff0c;…
阅读更多...
Day02 Liunx高级程序设计2-文件IO

Day02 Liunx高级程序设计2-文件IO

系统调用 概念 是操作系统提供给用户使其可以操作内核提供服务的一组函数接口 用户态和内核态 其中 ring 0 权限最高&#xff0c;可以使用所有 CPU 指令&#xff0c; ring 3 权限最低&#xff0c;仅能使用 常规 CPU 指令&#xff0c;这个级别的权限不能使用访问硬件资…
阅读更多...
解决 vite 中 import.meta.globEager is not function 的问题

解决 vite 中 import.meta.globEager is not function 的问题

本人正在重构两年前搭建到一半的博客网站&#xff0c;相关依赖都很陈旧&#xff0c;用到了 npm-check-updates 检测项目可升级依赖&#xff1a; 升级完成后解决完依赖发现控制台报错 import.meta.globEager is not function解决方案&#xff1a; vite版本降至4.3.0 亲测有效&…
阅读更多...
Shell数组函数：数组（二）

Shell数组函数：数组（二）

关联数组 注意&#xff1a;先声明关联数组 一、定义关联数组 方法一 #一次赋一值 #数组名[索引]变量值 [rootlocalhost ~]# declare -A ass_array1 [rootlocalhost ~]# ass_array1[index1]pear [rootlocalhost ~]# ass_array1[index2]apple [rootlocalhost ~]# ass_array1[ind…
阅读更多...
gpt阅读论文利器

gpt阅读论文利器

1. txyz.ai 读论文 严伯钧 3. consensus 两亿科学论文的资源库. 用英文. 中国经济发展, 美国加州没有,减肥没有. 2. chrome插件 gpt sidebar 3. gpt academic 论文润色和学术翻译 ,一键输出公式. 英语口语8000句. 托福备考计划表. 百词斩托福. 薄荷外刊. 分区笔记精读法.…
阅读更多...
Container容器技术简介

Container容器技术简介

本文介绍了容器技术出现背景&#xff0c;docker技术与容器编排技术的简单说明 背景 在传统项目的生产环境中&#xff0c;迁移一个用户态进程往往非常麻烦&#xff0c;因为一个用户态进程背后会附带这非常多例如函数库、中间件等的依赖项&#xff0c;但又没有像apt和yum一样的…
阅读更多...
广州华锐互动：钢铁厂烫伤事故3D模拟急救演练提高企业应对突发事故能力

广州华锐互动：钢铁厂烫伤事故3D模拟急救演练提高企业应对突发事故能力

随着工业化进程的加快&#xff0c;钢铁行业作为国家经济的重要支柱产业&#xff0c;其安全生产问题日益受到社会各界的关注。近年来&#xff0c;我国钢铁企业不断加大安全生产投入&#xff0c;但事故频发的现象仍然时有发生。为了提高钢铁企业应对突发事故的能力&#xff0c;确…
阅读更多...
如何使用llm 制作多模态

如何使用llm 制作多模态

首先将任何非字符的序列信息使用特殊n个token 编码。 具体编码方法以图像为例子说明&#xff1a; 将固定尺寸图像如256256 的图像分割为1616 的子图像块。 将已知的所有图像数据都分割后进行str将其看做是一个长的字符&#xff0c;而后去重后方式一个词表。 使用特殊1024 个tok…
阅读更多...
推荐6款本周 火火火火 的开源项目

推荐6款本周 火火火火 的开源项目

本周 GitHub项目圈选 节选自微博、知乎、掘金等社区。 &#x1f525;&#x1f525;&#x1f525;本周推荐的开源项目是&#xff1a; kopia 日常备份工具 screenshot-to-code 截屏生成代码 MiniSearch 全文搜索 clone-voice 声音克隆 NvChad 高颜值终端 DB-GPT-Hub 文本到…
阅读更多...
关于 Kubernetes中Admission Controllers(准入控制器) 认知的一些笔记

关于 Kubernetes中Admission Controllers(准入控制器) 认知的一些笔记

写在前面 工作中遇到&#xff0c;简单整理记忆博文为官方文档整理涉及内置准入控制的分类理解理解不足小伙伴帮忙指正 人活着就是为了忍受摧残&#xff0c;一直到死&#xff0c;想明了这一点&#xff0c;一切事情都能泰然处之 —— 王小波《黄金时代》 为什么需要准入控制器 准…
阅读更多...
怎样的软件测试工程师才算“大神“？“我“的测试之路...

怎样的软件测试工程师才算“大神“？“我“的测试之路...

目录&#xff1a;导读 前言一、Python编程入门到精通二、接口自动化项目实战三、Web自动化项目实战四、App自动化项目实战五、一线大厂简历六、测试开发DevOps体系七、常用自动化测试工具八、JMeter性能测试九、总结&#xff08;尾部小惊喜&#xff09; 前言 个优秀的软件测试…
阅读更多...
6.Eclipse里下载Subclipse插件

6.Eclipse里下载Subclipse插件

方法一&#xff1a;从Eclipse Marketplace里面下载 具体操作&#xff1a;打开Eclipse --> Help --> Eclipse Marketplace --> 在Find中输入subclipse搜索 --> 找到subclipse点击install 方法二&#xff1a;从Install New Software里下载 具体操作&#xff1a;打开…
阅读更多...
RPC基础

RPC基础

RPC基础知识 RPC 是什么? RPC&#xff08;Remote Procedure Call&#xff09; 即远程过程调用&#xff0c;通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。 为什么要 RPC &#xff1f; 因为&#xff0c;两个不同的服务器上的服务提供的方法不在一个内存空间&…
阅读更多...
【从零认识ECS云服务器 | 快速上线个人网站】一、ECS概述

【从零认识ECS云服务器 | 快速上线个人网站】一、ECS概述

首先我们来说什么是服务器&#xff0c;服务器本身就是一种电脑&#xff0c;和我们日常使用的电脑一样&#xff0c;同样具备CPU、内存、硬盘、网卡、电源等硬件&#xff0c;但是由于服务器是24小时不间断运行&#xff0c;所以需要更加强大的配置来支撑其运行&#xff0c;以保障公…
阅读更多...
【c】16进制数转化为10进制数（计算方法在最后，大家也可以上网搜索视频，视频更详细，谢谢）

【c】16进制数转化为10进制数（计算方法在最后，大家也可以上网搜索视频，视频更详细，谢谢）

#include<stdio.h> #include<math.h> void trans(char arr1[],int arr[],int n) {puts("请输入16进制的数");for(int i0;i<n;i){scanf("%c",&arr1[i]);arr[i](int)arr1[i];}for(int k0;k<n;k){if(arr[k]>65&&arr[k]<7…
阅读更多...
Java的第二十一章：网络通信

Java的第二十一章：网络通信

网络程序设计基础 网络程序设计编写的是与其他计算机进行通信的程序。Java 已经将网络程序所需要的元素封装成不同的类&#xff0c;用户只要创建这些类的对象&#xff0c;使用相应的方法&#xff0c;即使不具备有关的网络支持&#xff0c;也可以编写出高质量的网络通信程序。 …
阅读更多...
Gee教程6.模板(HTML Template)

Gee教程6.模板(HTML Template)

这一章节的内容是介绍 Web 框架如何支持服务端渲染的场景 实现静态资源服务(Static Resource)。支持HTML模板渲染。 这一章节很多内容是基于net/http库的&#xff0c;该库已经实现了很多静态文件和HMML模板的相关功能的了。 静态文件 网页的三剑客&#xff0c;JavaScript、C…
阅读更多...
CentOS增加虚拟内存 (Linux增加内存)

CentOS增加虚拟内存 (Linux增加内存)

前言 因为囊中羞涩不敢言&#xff0c;所以内存只有2G&#xff0c;项目在运行的时候&#xff0c;占用的内存已经报表&#xff0c;所以有的时候就会出现宕机的情况发生&#xff0c;后面发现可以通过使用增加虚拟内存空间&#xff0c;来增加内存容量。 下面进入正题&#xff0c;讲…
阅读更多...
聊聊 Jetpack Compose 原理 -- Compose 是如何将数据转换成 UI 的？

聊聊 Jetpack Compose 原理 -- Compose 是如何将数据转换成 UI 的？

Compose 是一个声明式的 UI 框架&#xff0c;提供了很多开箱即用的组件&#xff0c;比如 Text()、Button、Image() 等等&#xff0c;Compose 会经过几个不同的阶段&#xff0c;最终渲染出 UI 界面。 此转换过程分为【三个阶段】&#xff1a; 组合&#xff1a; 显示什么布局&a…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023