Redis 性能优化选择:Pika 的配置与使用详解

引言

在我们日常开发中 redis是我们开发业务场景中不可缺少的部分。Redis 凭借其内存存储和快速响应的特点,广泛应用于缓存、消息队列等各种业务场景。然而,随着数据量的不断增长,单节点的 Redis 因为内存限制和并发能力的局限,逐渐难以支撑高并发的请求。为了解决这些问题,我们通常会采用 搭建Redis 集群方案来解决高并发下的限制问题。然而,Redis 集群的部署往往需要更高的资源投入,巨大的内存需求和运维成本带来了不小的压力。除此之外,集群模式下的数据分片和一致性问题,也让系统设计的复杂度大大增加。

在这种高并发、大流量的业务场景下,我们是否能够在追求 Redis 高性能的同时,找到更经济高效的大数据解决方案呢?除了 Redis 集群方案外,今天我将介绍一种可以替代 Redis 集群的方案,也是我在以往开发中广泛使用的一种数据结构——Pika。Pika 在兼容 Redis API 的基础上,将数据存储在磁盘上,突破了内存限制,尤其适合大数据存储和高并发访问的需求。


什么是 Pika?

Pika 是一种兼容 Redis 协议的高效存储引擎,设计初衷就是为了解决 Redis 在大数据场景下因内存限制而带来的瓶颈问题。与 Redis 将数据存储在内存中的方式不同,Pika 将数据存储在磁盘上,从而有效扩展存储容量,适应大规模数据的需求。当 Redis 的内存使用量超过 16 GiB 时,会面临多种限制,如内存容量受限、单线程阻塞、启动恢复时间长、内存硬件成本高、缓冲区容易填满、一主多从故障时的切换成本高等。Pika 的出现并非为了替代 Redis,而是为了补充 Redis,以便在大数据场景下依然保持高性能。Pika 力求完全遵守 Redis 协议,继承 Redis 便捷的运维设计,同时通过持久化存储来突破 Redis 在数据量巨大时内存容量不足的瓶颈。此外,Pika 支持通过 slaveof 命令进行主从模式配置,支持全量和增量数据同步,方便在大数据和高可用场景下的灵活扩展。

Pika 的兼容性

Pika 兼容 Redis 中的 stringhashlistzsetset 五大核心数据类型,能够支持大部分与之相关的操作接口(兼容详情可查阅官方文档),实现了几乎所有 Redis 的基本操作需求。这意味着,现有的 Redis 客户端和命令都可以无缝迁移到 Pika 上使用,无需额外学习新的命令或语法。

Pika 的主从备份能力

与 Redis 一样,Pika 支持通过 slaveof 命令进行主从复制,提供可靠的备份和高可用性支持。同时,Pika 实现了全同步和部分同步机制,能够在数据同步中做到既灵活又高效,确保数据一致性和稳定性。这样,Pika 既保留了 Redis 数据复制的优势,又在容量上扩展了存储空间,可以在不更改代码的前提下快速接入生产环境。

为什么选择 Pika?

Pika 提供了与 Redis 一致的使用体验,且不需要额外的学习和开发成本。相较于 Redis,Pika 的优势体现在以下几方面:

  1. 更大的存储容量:Pika 通过磁盘存储解决了 Redis 的内存瓶颈问题,适合大规模数据场景。
  2. 无缝替换:Pika 兼容 Redis 绝大多数核心命令,因此在功能实现和操作上与 Redis 几乎无异,用户不必更改现有代码或熟悉新的命令,即可将 Pika 集成到现有系统中。
  3. 高可用性和备份支持:Pika 支持主从复制、全同步和部分同步,确保数据可靠性和高并发访问。

Pika 的适用场景

Pika 的设计非常适合以下几种高容量、高并发的数据场景:

  1. 大数据量缓存:对于数据规模庞大的应用,比如实时数据处理、日志收集和分析场景,Pika 的磁盘存储使它能轻松应对 TB 级数据,不再受限于内存容量。适用于金融、广告、物联网等需要存储大量实时数据的行业。
  2. 高并发访问场景:在流量密集型业务中,如电商、游戏和社交网络,Pika 能够支持高并发访问需求,与 Redis 一样实现快速的数据读写,但在资源消耗上更经济。
  3. 长时间数据存储:在日志存储、历史数据存储等业务中,数据需要长时间保留,但访问频率相对较低。Pika 的磁盘持久化存储方式为此类场景提供了低成本的替代方案,不会因数据量增加而导致内存压力上升。
  4. 分布式集群环境:对于需要高可用性的数据集群应用,Pika 的主从复制和同步功能使其可以在分布式环境中稳定运行,支持多节点备份和容灾切换,确保数据的高可靠性和一致性。

Pika使用用户

在这里插入图片描述

Pika 已被各大公司广泛采用,用于内部部署,证明了其可扩展性和可靠性。一些值得注意的使用实例包括:

  • 360公司:内部部署,规模10000+实例,单机数据量1.8TB。
  • 微博:内部部署,有10000+个实例。
  • 喜马拉雅(Xcache) :6000+实例,海量数据超过120TB。
  • 个推 公司:内部部署,300+实例,累计数据量超过30TB。

此外,迅雷、小米、知乎、好未来、快手、搜狐、美团、脉脉等公司也在使用 Pika。有关完整用户列表,可以参考 Pika 项目提供的官方列表。

这些在不同公司和行业的部署凸显了 Pika 在处理大规模、大容量数据存储需求方面的适应性和有效性。


接下来,我将展示如何安装 Pika,并进行简单的使用示例,以便快速上手并体验 Pika 的性能。

安装之前我们先看下官方给的安装示例:安装示例

我按照官方的安装示例 安装的是v4.0.1最新版本及之前版本。但是我一直未make或build成功。不知道是不是我自己环境的问题。

本文章采用下载安装包的形式来安装
  1. 首先我们去版本库下载对应版本的安装包(我选择是v3.3.0)

    在这里插入图片描述

  2. 将安装包上传到 /usr/local/pika 目录中,便于管理:

    sudo mkdir -p /usr/local/pika
    
  3. 然后解压该安装包

    sudo tar -xvf  pika-linux-x86_64-v3.3.0.tar.bz2 
    

    在这里插入图片描述

  4. 解压完成后会生成一个output文件夹,接下来我们执行命令启动

       ./output/bin/pika -c ./output/conf/pika.confb
    
  5. 我第一次启动报错了 报错如下:

    在这里插入图片描述

    • 这个错误提示主要有两个原因:1. Rsync 失败pika_rsync_service.cc:48 报错提示无法启动 rsync 服务,可能是 rsync 没有安装或者路径配置有问题。
      2. 端口绑定失败:提示 bind port 10221 failed,表示 Pika 无法绑定端口 10221,可能是端口被占用,或者当前用户权限不足。

    • Pika 使用 rsync 进行数据同步,请确保系统已安装 rsync

      sudo yum install -y rsync
      

      安装完成后,重新尝试启动 Pika。

    • 使用以下命令检查是否有其他进程占用了 10221 端口:

      sudo lsof -i :10221
      

      如果有其他进程占用端口,可以尝试停止占用端口的进程,或者更改 Pika 的端口配置。

解决上面问题后 我尝试重新启动,可以看到已经成功启动:

在这里插入图片描述

启动成功后我们另开一个窗口来测试操作简单命令:

在这里插入图片描述


我们来大概看下安装的Pika配置文件 在output/conf下的pika.conf:

# Pika port
port : 9221  # Pika 监听的端口

# Thread Number
thread-num : 1  # 用于处理客户端请求的工作线程数

# Thread Pool Size
thread-pool-size : 12  # 线程池大小,用于处理并发任务

# Sync Thread Number
sync-thread-num : 6  # 用于主从同步的线程数

# Pika log path
log-path : ./log/  # 日志文件的存储路径

# Pika db path
db-path : ./db/  # 数据库文件的存储路径

# Pika write-buffer-size
write-buffer-size : 268435456  # 写缓冲区大小,单位为字节(256MB)

# Pika timeout
timeout : 60  # 客户端连接空闲超时时间,单位为秒

# Requirepass
requirepass :  # 设置管理员密码,用于验证高权限操作

# Masterauth
masterauth :  # 从节点连接主节点时的认证密码

# Userpass
userpass :  # 普通用户连接的密码

# User Blacklist
userblacklist :  # 黑名单用户列表,拒绝指定用户访问

# Pika instance mode [classic | sharding]
instance-mode : classic  # Pika 的实例模式:classic 为多数据库模式,sharding 为分片模式

# Set the number of databases. Limited in [1, 8]
databases : 1  # 数据库数量,仅在 classic 模式下有效

# default slot number each table in sharding mode
default-slot-num : 1024  # 每张表的分片数量,仅在 sharding 模式下有效

# replication num defines followers in a single raft group, limited in [0, 4]
replication-num : 0  # Raft 组中的从节点数量

# consensus level defines confirms before commit to client
consensus-level : 0  # 主节点提交前需要的确认数量,用于 Raft 一致性协议

# Dump Prefix
dump-prefix :  # 导出文件的前缀,用于数据持久化文件命名

# daemonize  [yes | no]
#daemonize : yes  # 是否以守护进程方式运行(后台运行)

# Dump Path
dump-path : ./dump/  # 数据导出路径

# Expire-dump-days
dump-expire : 0  # 数据导出的过期天数(0 表示不过期)

# pidfile Path
pidfile : ./pika.pid  # Pika 进程 ID 文件路径

# Max Connection
maxclients : 20000  # 最大客户端连接数

# the per file size of sst to compact, default is 20M
target-file-size-base : 20971520  # 每个 SST 文件的目标大小(20MB)

# Expire-logs-days
expire-logs-days : 7  # 日志文件的过期天数

# Expire-logs-nums
expire-logs-nums : 10  # 日志文件的最大数量

# Root-connection-num
root-connection-num : 2  # root 用户的最大连接数

# Slowlog-write-errorlog
slowlog-write-errorlog : no  # 慢查询日志是否写入错误日志文件

# Slowlog-log-slower-than
slowlog-log-slower-than : 10000  # 慢查询记录的时间阈值,单位为微秒

# Slowlog-max-len
slowlog-max-len : 128  # 慢查询日志的最大条数

# Pika db sync path
db-sync-path : ./dbsync/  # 数据同步文件的存储路径

# db sync speed(MB) max is set to 1024MB, min is set to 0
db-sync-speed : -1  # 主从同步的最大速度,单位为 MB/s,-1 表示无限制

# The slave priority
slave-priority : 100  # 从节点的优先级

# network interface
#network-interface : eth1  # 网络接口(可以指定特定的网卡)

# replication
#slaveof : master-ip:master-port  # 设置为从节点并指定主节点地址和端口

# CronTask, e.g., 02-04/60 for compaction between 2-4am every day
#compact-cron : 3/02-04/60  # 压缩任务计划:在每周三的 2-4 点进行压缩

# Compact-interval, e.g., 6/60 checks compaction every 6 hours
#compact-interval :  # 压缩间隔,单位为小时。比 compact-cron 优先

# sync window size for binlog between master and slave, default is 9000
sync-window-size : 9000  # 主从同步的 binlog 窗口大小

# max connection read buffer size, default is 256MB
max-conn-rbuf-size : 268435456  # 最大读取缓冲区大小

###################
## Critical Settings
###################
# write_binlog  [yes | no]
write-binlog : yes  # 是否开启 binlog 日志记录

# binlog file size: default is 100M,  limited in [1K, 2G]
binlog-file-size : 104857600  # binlog 文件大小限制(100MB)

# Use cache to store up to 'max-cache-statistic-keys' keys
max-cache-statistic-keys : 0  # 缓存的统计键的最大数量,0 表示关闭此功能

# Trigger small compaction after deleting/overwriting keys
small-compaction-threshold : 5000  # 触发小压缩的操作次数阈值

# Flush triggered if all live memtables exceed this limit
max-write-buffer-size : 10737418240  # 所有 memtables 的总内存大小上限(10GB)

# Limit some command response size
max-client-response-size : 1073741824  # 限制响应大小的最大值(1GB)

# Compression type supported [snappy, zlib, lz4, zstd]
compression : snappy  # 数据压缩类型

# max-background-flushes: default is 1, limited in [1, 4]
max-background-flushes : 1  # 后台刷新任务的最大数量

# max-background-compactions: default is 2, limited in [1, 8]
max-background-compactions : 2  # 后台压缩任务的最大数量

# Maximum cached open file descriptors
max-cache-files : 5000  # 缓存的最大打开文件描述符数量

# max_bytes_for_level_multiplier: default is 10, can change to 5
max-bytes-for-level-multiplier : 10  # RocksDB 层次的最大字节数乘数

# BlockBasedTable block_size, default 4k
# block-size: 4096  # 块表的块大小(4KB)

# block LRU cache, default 8M, 0 to disable
# block-cache: 8388608  # LRU 块缓存大小(8MB)

# whether the block cache is shared among RocksDB instances
# share-block-cache: no  # 是否在多个 RocksDB 实例之间共享块缓存

# whether index and filter blocks are in block cache
# cache-index-and-filter-blocks: no  # 是否将索引和过滤块放入块缓存

# bloomfilter of the last level will not be built if set to yes
# optimize-filters-for-hits: no  # 是否优化最后一层的布隆过滤器

# Enables dynamic levels target size for compaction
# level-compaction-dynamic-level-bytes: no  # 是否启用动态级别的压缩目标大小

根据配置文件的配置项可以根据自己的需求更改


在每次启动时手动执行启动命令既麻烦又不便于管理。为此,我们可以通过 Systemd 配置一个服务,使 Pika 开机自启并便于系统控制,提升管理效率。

配置启动服务

  1. 创建 Pika 系统用户

    为了提高安全性,创建一个专用的系统用户和用户组来运行 Pika(在/usr/local/pika下执行):

    sudo groupadd --system pika
    sudo useradd -M -s /sbin/nologin -g pika -d /usr/local/pika pika
    
  2. 设置文件拥有者

    chown -R pika:pika output
    
  3. 配置 Pika 作为 Systemd 服务

    /usr/lib/systemd/system 目录下创建 pika.service 文件:

    cat > /usr/lib/systemd/system/pika.service <<EOF
    
    [Unit]
    Description=pika server
    Requires=network.target
    After=network.target
    
    [Service]
    User=pika
    Group=pika
    Type=forking
    WorkingDirectory=/usr/local/pika/output
    ExecStart=/usr/local/pika/output/bin/pika -c /usr/local/pika/output/conf/pika.conf
    Restart=always
    
    [Install]
    WantedBy=multi-user.target
    EOF
    

    确保 WorkingDirectory 路径是有效的目录,并且已经在系统中正确创建。根据您之前的路径配置,将 WorkingDirectory 修改为实际存在的路径,例如:WorkingDirectory=/usr/local/pika/pika-v4.0.1
    ExecStart=/usr/local/pika/pika-v4.0.1-alpha/output/pika -c /usr/local/pika/pika-v4.0.1-alpha/conf/pika.conf

  4. 增加文件描述符限制

    为确保高并发场景下的稳定性,增加文件描述符的限制:

  • 创建 pika.service.d 目录:

    sudo mkdir -p /etc/systemd/system/pika.service.d
    
  • 在该目录下创建 limit.conf 文件:

    sudo cat > /etc/systemd/system/pika.service.d/limit.conf <<EOF 
    [Service] 
    LimitNOFILE=65536 
    EOF
    
  1. 启动和管理 Pika 服务

    完成配置后,可以使用以下命令来管理 Pika:

    # 重新加载 systemd 配置文件
    sudo systemctl daemon-reload 
    
    # 启动 Pika 服务 
    sudo systemctl start pika
    
    # 设置 Pika 开机启动 
    sudo systemctl enable pika 
    
    # 检查服务状态 
    sudo systemctl status pika
    

通过以上步骤,Pika 已成功安装并配置为 systemd 服务,支持自动启动、停止和重启管理,方便在生产环境中使用。这样不仅简化了管理,还提高了服务的稳定性。


注意事项

在安装和配置 Pika 后,以下几点是需要特别注意的,以便更好地理解 Pika 的使用场景和性能表现:

  1. 线程模型
    Pika 是多线程设计,不同于 Redis 的单线程模型,这使得 Pika 能在大多数多核 CPU 环境下有效地处理更多的并发请求。这种设计更适合于大量数据的场景,尤其是在持久化存储需求强烈的场合。

  2. 适用场景

    • 大数据、高容量场景:Pika 在大数据和持久化存储的场景下更具优势。例如,当 Redis 内存超出 16GB 后可能出现瓶颈,Pika 则通过将数据存储在磁盘上而不依赖于内存,有效解决了存储容量的限制问题。
    • 写密集型操作:在写密集型操作时,Pika 的多线程设计使其在高并发写入场景中表现更优。
  3. 性能限制
    虽然 Pika 在某些场景下优于 Redis,但它并非在所有情况下都优于 Redis,也不能完全取代 Redis。在高性能内存操作和极低延迟需求的场景下,例如高速缓存、实时性极高的操作,Redis 的内存操作速度更具优势。

  4. 主从同步和故障恢复
    Pika 支持通过 slaveof 命令配置主从关系,但其同步机制依赖于磁盘 I/O,可能会导致与 Redis 相比稍微较慢的同步速度。对于高频数据变更或对数据实时性要求较高的场景,可能仍需要 Redis 提供更快的响应。

  5. 存储开销
    因为 Pika 依赖磁盘存储,所以需要保证存储空间充足并定期清理过期数据。过大的数据集可能会导致磁盘 I/O 增加,从而对系统的整体性能产生影响。

  6. 选择依据
    Pika 并不是 Redis 的完全替代品。在决定使用 Pika 或 Redis 时,最好结合业务场景:如果数据量较小且关注内存操作的速度,Redis 更合适;而在持久化需求高、数据量大或关注磁盘存储扩展性的场景下,Pika 更适用。


最后

Pika 作为一种兼容 Redis 协议的高效存储引擎,在大数据和持久化存储需求的业务场景中,为 Redis 用户提供了一个强有力的补充方案。Pika 通过将数据存储在磁盘上,有效突破了 Redis 在内存容量上的限制,同时保持了 Redis 的高效操作体验和简便的管理特性。得益于多线程设计,Pika 能在写密集和大容量场景中表现优异,尤其适合那些对数据持久化、扩展性要求较高的场合。

然而,Pika 并非 Redis 的完全替代品。在需要极低延迟、以缓存为核心的场景中,Redis 仍然具备不可替代的优势。因此,选择 Pika 或 Redis 需要结合具体的业务需求,权衡各自的优缺点。总体而言,Pika 在特定的应用场景下能够发挥重要作用,是 Redis 在大数据场景中的有益补充。希望通过本次配置和使用指南,大家能够更好地理解 Pika 的特性和适用性,为项目需求提供更高效的解决方案。

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

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

ONLYOFFICE文档8.2:开启无缝PDF协作

ONLYOFFICE 开源办公套件的最新版本新增约30个新功能&#xff0c;并修复了超过500处故障。 什么是 ONLYOFFICE 文档 ONLYOFFICE 文档是一套功能强大的文档编辑器&#xff0c;支持编辑处理文档、表格、幻灯片、可填写的表单和PDF。可多人在线协作&#xff0c;支持插件和 AI 集…

论文解读 | ECCV2024 AutoEval-Video:一个用于评估大型视觉-语言模型在开放式视频问答中的自动基准测试...

点击蓝字 关注我们 AI TIME欢迎每一位AI爱好者的加入&#xff01; 点击 阅读原文 观看作者讲解回放&#xff01; 作者简介 陈修元&#xff0c;上海交通大学清源研究院硕士生 概述 总结来说&#xff0c;我们提出了一个新颖且具有挑战性的基准测试AutoEvalVideo&#xff0c;用于全…

红队-安全见闻篇(上)

声明 学习视频来自B站UP主 泷羽sec的个人空间-泷羽sec个人主页-哔哩哔哩视频,如涉及侵权马上删除文章 笔记的只是方便各位师傅学习知识,以下网站只涉及学习内容,其他的都与本人无关,切莫逾越法律红线,否则后果自负 一.编程与开发 1.后端语言学习 C语⾔&#xff1a;⼀种通⽤的…

NVR小程序接入平台/设备EasyNVR多个NVR同时管理的高效解决方案

在当今的数字化安防时代&#xff0c;视频监控系统的需求日益复杂和多样化。为了满足不同场景下的监控需求&#xff0c;一种高效、灵活且兼容性强的安防视频监控平台——NVR批量管理软件/平台EasyNVR应运而生。本篇探讨这一融合所带来的创新与发展。 一、NVR监测软件/设备EasyNV…

053_python基于深度学习的短视频内容理解与推荐系统

目录 系统展示 开发背景 代码实现 项目案例 获取源码 博主介绍&#xff1a;CodeMentor毕业设计领航者、全网关注者30W群落&#xff0c;InfoQ特邀专栏作家、技术博客领航者、InfoQ新星培育计划导师、Web开发领域杰出贡献者&#xff0c;博客领航之星、开发者头条/腾讯云/AW…

如何实现海内外工厂的EDI对接?

企业在国际市场的扩张需要高效的信息流动&#xff0c;以便快速响应客户需求。但国内工厂和海外工厂使用的系统可能存在兼容性问题&#xff0c;且数据格式各不相同&#xff0c;集成过程复杂。 近期国内主营高精度滚动轴承的汽车行业C公司就遇到了这样的挑战&#xff0c;如何实现…

linux查看文件命令

查看文件命令 显示命令 cat 语法&#xff1a;cat 【选项】 文件 选项 命令含义n显示行号包括空行b显示行号不包括空行s压缩空行为一行A显示隐藏字符 cat -n 文件&#xff1a;显示行号包括空行 cat -b 文件 cat -s 文件 cat -A 文件 more和less是 分页查看 tac和rev都…

python实战项目47:Selenium采集百度股市通数据

python实战项目47:Selenium采集百度股市通数据 一、思路分析二、完整代码一、思路分析 这里以获取百度股市通股评下的投票数据为例,页面中的其他数据同理。由于此页面数据是js动态加载的,所以采用Selenium获取数据。思路很简单,通过Selenium打开页面,然后定位到“股评”选…

502 错误码通常出现在什么场景?

服务器过载场景 高流量访问&#xff1a;当网站遇到突发的高流量情况&#xff0c;如热门产品促销活动、新闻热点事件导致网站访问量激增时&#xff0c;服务器可能会因承受过多请求而无法及时响应。例如&#xff0c;电商平台在 “双十一” 等购物节期间&#xff0c;大量用户同时…

Java 多线程(七)—— 定时器

定时器介绍与使用 先简单介绍一下什么是定时器&#xff1a;定时器类似生活中的闹钟&#xff0c;当时间一到&#xff0c;我们就会去做某些事情。 在代码层面理解就是&#xff0c;当我们设置的时间一到&#xff0c;程序就会执行我们固定的代码片段&#xff08;也就是任务&#x…

Nacos-Sync-未授权进后台(建议自查)

Nacos-Sync-未授权进后台&#xff08;建议自查&#xff09; 漏洞成因 没进行权限校验。 影响范围 Nacos-Sync 3.0 发现方式 一、fofa发现 title“nacos” && title“Nacos-Sync” 二、路径拼接 /#/serviceSync 利用方式 访问之后直接是进入后台的样子~ 修复方…

【AI视频抠图整合包及教程】开启视觉分割新纪元 —— Meta SAM 2

在数字化时代&#xff0c;Meta公司推出的SAM 2&#xff08;Segment Anything Model 2&#xff09;标志着图像和视频分割技术的一个新高度。SAM 2不仅继承了前代SAM模型的卓越性能&#xff0c;更在实时处理、视频分割、交互式提示等方面实现了重大突破。以下是SAM 2的全面营销文…

【植物识别系统】Python+人工智能+深度学习+卷积神经网络算法+TensorFlow+算法模型+Django网页界面平台

一、介绍 植物识别系统&#xff0c;使用Python作为主要编程语言开发&#xff0c;通过收集常见的6中植物树叶&#xff08;‘广玉兰’, ‘杜鹃’, ‘梧桐’, ‘樟叶’, ‘芭蕉’, ‘银杏’&#xff09;图片作为数据集&#xff0c;然后使用TensorFlow搭建ResNet50算法网络模型&am…

如何通过Lua语言请求接口拿到数据

文章目录 概要http客户端通过请求下载数据 概要 当某个需求是需要在模块内请求接口拿到数据&#xff0c;需要使用http客户端调用接口 http客户端 LuaSOC请求接口官方文档 调用&#xff1a;http.request(method,url,headers,body,opts,ca_file,client_ca, client_key, clien…

【日记】感觉沟通是件很难精通的事情(1397 字)

正文 今天霜降&#xff0c;感觉得开始戴手套了&#xff0c;去年就是因为戴得早&#xff0c;所以避免了生冻疮。不知道今年还会不会有这么幸运。虽然霜降&#xff0c;但意外地天气很好呢。下午又找了个时间稍微偷溜出去发了一会儿呆。可惜每次下班天都黑了&#xff0c;天气好的话…

HCIP--1

同一区域内的OSPF路由器拥有一致的 LSDB, 在区域内&#xff0c;OSPF 采用 SPF算法计算路由一个区域太多路由器&#xff0c;硬件资源跟不上&#xff0c;所以多划分区域 OSPF 路由计算原理 1. 区域内路由计算 LSA 在OSPF中&#xff0c;每个路由器生成 LSA&#xff0c;用于告诉…

基于SpringBoot的宠物爱好者交流系统的设计与实现(源码+定制+开发)

博主介绍&#xff1a; ✌我是阿龙&#xff0c;一名专注于Java技术领域的程序员&#xff0c;全网拥有10W粉丝。作为CSDN特邀作者、博客专家、新星计划导师&#xff0c;我在计算机毕业设计开发方面积累了丰富的经验。同时&#xff0c;我也是掘金、华为云、阿里云、InfoQ等平台…

Facebook的AI驱动发展:人工智能如何改变社交体验

个性化内容推荐 Facebook利用AI算法分析用户的行为数据&#xff0c;包括点赞、评论、分享和浏览历史。这些数据使得平台能够深入了解用户的兴趣和偏好&#xff0c;从而提供个性化的内容推荐。例如&#xff0c;用户在浏览动态时&#xff0c;AI系统会根据用户的互动历史&#xf…

快速获取 GitHub 个人资料成就徽章

效果展示 成就徽章 个人资料中可以选择是否显示成就徽章&#xff0c;Settings-Public profile&#xff0c;勾选Show Achievements on my profile。 徽章名称获取方式Heart On Your Sleeve使用 ❤️ 表情符号对 GitHub 上的内容做出反应 (正在测试中)Open Sourcerer用户已将 P…

【芯片设计】DC综合retiming策略的学习与实践

对于DC综合中的retiming策略早有耳闻&#xff0c;但是一直没有比较系统的学习和实验过&#xff0c;正好借着这次交付过程的归纳总结机会&#xff0c;把一些零零散散的收获学习记录下。 记得刚出新手村时和某位大佬聊到过&#xff0c;他说你逻辑里写了在某级计算一个结果&#…