标题: 佬友们平安快乐
作者: #WSHK
板块: #搞七捻三
编号: 1355550
帖子: https://linux.do/t/topic/1355550
时间: 2025-12-24 09:45:08
摘要:

平安夜快乐啊，顺便感谢一下黑与白公益站，感谢佬友的公益，也是成功集齐了一套坤坤，我是ikun

标题: GLM 7天体验
作者: #gaohdu99
板块: #福利羊毛
编号: 1355551
帖子: https://linux.do/t/topic/1355551
时间: 2025-12-24 09:45:09
摘要:

总结 (click for more details)

标题: 【闲聊】内娱粉丝和我
作者: #夜
板块: #搞七捻三
编号: 1355562
帖子: https://linux.do/t/topic/1355562
时间: 2025-12-24 09:47:12
摘要:

最近我发现，内娱粉丝在说屏蔽词条，别给对家眼神之类，大家文化水平提高了啊…这至少要知道推送逻辑。
我没粉过哪个明星，看到粉丝话语，第一反应就是，跟我一样。
其实我手机上没有任何短视频软件，大部分时候，我的电脑也不登录微信qq，我坚持运动和冥想，睡前会做呼吸训练，练着练着就睡着了，甚至不做梦。
因为我希望提升自己的专注力，然后我发现，粉丝在为明星打投的时候，专注跟我差不多，甚至会搞几百个小号做数据。
我想他们也没抱有多高尚的心思，就是想保护帮助自己喜欢的明星，就像我做训练，做一点，在做一点。
很多人其实不反对像信徒一样生活，尽管他们没有意识到。
戒律可以让人温暖，特别是跟他人一起，那种温暖是特别特别美好的。
再说说娱乐圈明星，明星做点什么都要搞造型，无心之举，可能找来大批谩骂。我想到的，其实是现代的宫斗故事。
那种宫斗故事，跟古代后宫，其实特别不一样，比较稳定的朝代，皇帝也不是太叛逆，妃子晋升遵守严格规矩，比如说，孩子生的多，比如入宫侍奉皇帝很久，如果是乱世，没背景的妃子说死就死。
真实的后宫，其实特别不适合写面对大众的故事，因为理解门槛太高了，但是大众的文化水平在逐渐变高。
小白模板一定会被抛弃，如果作者看轻民众，作者一定会被民众忘记。
比较流行的宫斗故事会怎么样呢，某些妃子的晋升速度非常快，就跟明星一样，因为美貌，因为某个举动，或者因为皇帝（资本方），一夜就麻雀变凤凰。
这个设定还挺天才的，又疏远又亲近的，疏远指的是古代世界，亲近指的是娱乐圈，谁都有手机嘛。
其实如果，娱乐圈明星的辛苦，还挺贴近现在的学生和上班族，当然，是不富裕的阶层。
因为工位和学校都有摄像头，很多领导就是一拍脑门做决定，学生和职员就只能苦哈哈配合，跟长辈说也不会得到任何支持，因为长辈只会说忍，他们的一辈子就是忍过来的。
而且学生和大部分职员，都不从事生产，跟种地养家畜，是特别特别远的，巧了，明星也不会。
他们做的是荣誉性事务（跟礼仪一样，做就完事了），明星就是荣誉性事务的顶点，人就是会认出自己啊。
追星还挺好玩，又不孤独，又能追寻本行业龙头（？），也不需要怀疑信仰的真实，因为一搜就能看见明星，怎么会是假的？再加上屏蔽词条，大数据推送，纷乱世界一下子变得简单，甚至不用思考。
一个人要排外，首先得知道外界的存在，对于追星族，外界可以是不存在的。
物理意义上的心无外物。
如果是冥想，一个人起码要练习三个月，才能踏入心无外物的门槛，冥想是艰难的训练。
再看到那种明星，发一张图，就几万评论，心里确实羡慕，比我富多了。
（其实我也不懂l站，我本来一直发读书笔记的，但这个跟读书没多大关系，应该是发这个板块吧，写作也是我训练的一部分，好的，我的训练结束了）

标题: 星巴克买一送一
作者: #祝
板块: #福利羊毛
编号: 1355563
帖子: https://linux.do/t/topic/1355563
时间: 2025-12-24 09:47:32
摘要:

今天星巴克11:00后有买一送一的活动哦 各位续命佬可以看一看 参加活动的有：太妃榛果拿铁、太妃榛果星冰乐、比利时黑巧拿铁、比利时黑巧红茶拿铁 入口：淘宝闪购

标题: L站目前有移动APP端吗？
作者: #wendong
板块: #搞七捻三
编号: 1355574
帖子: https://linux.do/t/topic/1355574
时间: 2025-12-24 09:49:44
摘要:

如果有APP端就可以随时的刷了，如果有大家给指个地址

标题: auggie mcp内存占用异常高
作者: #Everless
板块: #搞七捻三
编号: 1355576
帖子: https://linux.do/t/topic/1355576
时间: 2025-12-24 09:50:11
摘要:

Ghostty 启用的claude code，在启用mcp之后内存占用飙升，活动监视器能看到auggie的node进程占用40多个G的内存，这正常吗，项目是比较大

标题: 可恶啊，我是昨天注册的LDC怎么还没有划转
作者: #linjinpeng
板块: #搞七捻三
编号: 1355580
帖子: https://linux.do/t/topic/1355580
时间: 2025-12-24 09:50:52
摘要:

都快10点怎么还没划转啊

标题: 想问一下各位佬，gemini pro的学生会员在使用Antigravity有claude 4.5模型和gemini 3模型可以用，不知道有多少额度呢
作者: #保持好情绪
板块: #搞七捻三
编号: 1355586
帖子: https://linux.do/t/topic/1355586
时间: 2025-12-24 09:51:46
摘要:

各位佬知道去哪里查看额度吗

标题: 企业使用AI，日常使用哪一个好一些？
作者: #桑榆
板块: #搞七捻三
编号: 1355588
帖子: https://linux.do/t/topic/1355588
时间: 2025-12-24 09:51:51
摘要:

如题，请教一下各位佬友，目前内部准备多部门使用（含IT岗，非IT岗），目前哪一个AI更好用？

期望：稳定，响应速度较快，回答效果较好（如果有国外模型好的中转站也欢迎分享）

目前，比较倾向于国内的AI(国内响应速度快)，最近出了GLM4.7、MiniMax2.1、DeepSeek v3.2，但不知道哪一个更好一些，佬友们推荐哪一个？
欢迎回复，感谢

标题: 在谷歌插件市场看到了本站的插件，问一下这是官方的吗？
作者: #cxyax
板块: #搞七捻三
编号: 1355597
帖子: https://linux.do/t/topic/1355597
时间: 2025-12-24 09:53:28
摘要:

各位佬们，这是官方的插件吗，不是官方的我不敢用哇 
看着评分倒是挺高的，5.0星

标题: 【国内信息差】And【吃瓜吃瓜】Redis Vs Valkey ，Redis还能继续用吗？！
作者: #秋明
板块: #开发调优
编号: 1355602
帖子: https://linux.do/t/topic/1355602
时间: 2025-12-24 09:54:00
摘要:

原文

  
    
    
    
      【国内信息差】龙头企业已换成ValKey了，你还在傻呵呵用Redis？！ 
  

开发调优
    
  
  
    Redis 风险评估与 Valkey 替代方案

这是为公司写的文档，因为这个信息差我在众多社区没有看到，担心部分佬友也不清楚，一起分享一下新信息。 
。 
国内的字节，阿里云，腾讯云等龙头企业都已经在逐步替换为ValKey 
而且 ValKey更像一个 “升级版真正开源的Redis” ，同时有多个龙头企业 贡献代码，性能这块甚至更强悍 


二编： 感谢各位大佬们一起讨论，让大家对于这个话题的了…
  


新编

前言： 这是为公司写的文档，因为最近（12月）字节和腾讯云将Redis替换为Valkey了 ，这个信息我在众多社区没有看到，担心部分佬友也不清楚，一起分享一下新信息以及原因。
感谢各位大佬们一起讨论，让大家对于这个话题的了解深度更上一层楼

Redis 风险评估与 Valkey 替代方案（更新版）

核心结论（先看结论）：

对绝大多数企业来说——只要不是云厂商、也不是把 Redis 当成对外售卖的 SaaS 服务，当前的 Redis 8.x 仍然可以放心使用。 作为内部业务组件做缓存/会话/分布式锁，不修改源码，许可证不会强制要求开源你的业务系统。
选型上可以简单理解为：

小 KV 基础缓存 + 低并发 + 单实例：优先选 Redis（升级到修复安全漏洞的稳定版本（即8.x版本）。
大 Key 较多 + 高并发（≥ 50 万 QPS）+ 集群规模大：更推荐 Valkey 8.x，性能、稳定性与成本综合优势明显。





一、背景与更新原因

早期版本的报告更偏重“Redis 风险”，在许可证和漏洞层面给出了较为保守的结论。
随着 Redis 8.x 采用三重许可证（AGPLv3 / RSALv2 / SSPLv1），以及社区对条款的实务解读逐渐清晰，现在可以更准确地划定风险边界：


除非你是云厂商 / 把 Redis 打包成收费服务卖给第三方，或大量修改 Redis 源码并以“在线服务”形式对外提供，否则正常使用基本不受限制。


同时，Valkey 生态在近一年快速成熟，性能和兼容性数据也更加充分，需要更新“Redis vs Valkey”的对比与选型建议。


二、Redis 8.x 许可证现状：三重许可证与实际影响
Redis 8.x（2025 年 5 月发布）采用 AGPLv3 / RSALv2 / SSPLv1 三重许可证 模式，用户可以在三者之间选择其一来合规使用。
2.1 三种许可证的核心差异（结合我们的典型用法）




许可证
对“企业内部使用 + 商业缓存”的影响
主要限制关注点




AGPLv3
完全可用，不修改源码时几乎无约束
仅当修改 Redis 源码并通过网络对外提供服务时，才需开源修改部分源码


RSALv2
完全可用，适合企业内部系统
禁止将 Redis 直接作为收费的托管服务 / 缓存服务对外提供


SSPLv1
完全可用，不修改源码时约束有限
若修改源码并对外提供服务，需要开源包括管理层在内的相关代码




对于我们这类 “应用系统” ，Redis 只是系统中的一个组件：

不单独对外售卖 Redis 托管服务。
通常也 不会大幅修改 Redis 源码。

在这种典型场景下，Redis 8.x 的许可证基本不会强制要求开源业务代码，可以放心使用。

2.2 “通过网络提供服务”的真实含义
以 AGPLv3 为例：“通过网络提供服务”指：

把修改过源码的 Redis 部署在服务器上，外部用户直接通过网络使用“这个被你修改过的 Redis 服务本身”。

而我们常见的情况是：

业务系统使用 原版 Redis 二进制或官方容器镜像 作为缓存 / 会话 / 锁组件；
对外提供的是“堆场系统 / 业务系统”的 API，而不是“Redis 访问服务”；

这与“运营一个 Redis 云服务平台”有本质区别。因此：

在不修改 Redis 源码的前提下，我们只要遵守基础条款（保留版权声明等），就可以在商业项目中安心使用 Redis。


三、安全风险：漏洞存在，但可通过“升级 + 运维治理”可控
Redis 近几年确实暴露了一些高危漏洞，但关键在于：

漏洞是否有修复版本可用？
我们是否能在可接受时间内完成升级与验证？

3.1 高危漏洞示例


CVE-2025-62507（CVSS 8.8，高危）

多 ID 场景下，XACKDEL 实现存在 栈缓冲区溢出 风险，在一定条件下可能被利用实现远程代码执行（RCE）。
受影响版本：Redis 8.2.0 及以上；8.2.3 已修复。
临时缓解手段：使用 ACL 禁用 / 限制相关命令。



CVE-2025-48367（CVSS 7.5）

在特定配置下，未认证连接 可以构造重复协议错误，让客户端陷入“饥饿”状态，导致 DoS 风险（服务不可用、请求超时）。
修复版本（NVD 公布）：8.0.3 / 7.4.5 / 7.2.10 / 6.2.19。



历史典型漏洞（已修复）：

Lua 脚本引擎 Use-After-Free（潜伏约 13 年，CVSS 10.0），在未做好认证的公开实例上，攻击者可远程执行任意代码。



3.2 对我们的实际影响与建议
影响本质在于“升级能力”，而不是“用不用 Redis”：

Redis 作为“公共枢纽”（缓存 / 会话 / 锁 / 消息），一旦被打挂或被入侵，影响会波及多个业务模块；
但这些漏洞都有已发布的修复版本，只要：

建立起 版本跟踪与定期升级机制；
避免将 Redis 暴露在公网或不可信网络环境；
开启并收紧认证与 ACL，按“最小权限”使用命令；



就可以把绝大部分安全风险控制在合理范围内。

因此，从安全角度看，Redis 仍然是可控的，不存在“必须抛弃 Redis 才安全”的结论，更多是对运维治理能力的要求。


四、Redis vs Valkey：性能与特性对比（综合最新评测）
基于近期 8.x 版本的实测数据（统一使用如 AWS c7g.4xlarge、redis-benchmark 和 memtier_benchmark 等工具），可得到较清晰的性能轮廓。
4.1 基础性能：小 KV、普通并发场景
在 小 KV（≈1KB）、中等并发（< 10 万 QPS） 的基础缓存场景中：

Redis 8.2.3 与 Valkey 8.0.1 在 QPS 与 P99 延迟差异不大，通常在几％ 到 10％ 左右；
对业务来说，两者在“体感性能”上几乎等价。

示例数据（1KB，小 KV，读写混合）：




场景
Redis 8.2.3
Valkey 8.0.1
差异（Valkey vs Redis）




1KB KV 100% 读
QPS：112 万，P99：0.9ms
QPS：119 万，P99：0.8ms
QPS ↑ 6.2%，延迟 ↓ 11.1%


1KB KV 7:3 读写混合
QPS：106 万，P99：1.0ms
QPS：113 万，P99：0.9ms
QPS ↑ 6.6%，延迟 ↓ 10%




结论： 对于“普通业务低并发 / 单实例缓存”而言，选择 Redis 还是 Valkey，在性能维度上差别不构成决定性因素，更多看生态习惯与团队成熟度。

4.2 大 Key、高并发与极限负载场景
当业务出现以下特征：

大量 大 Key（10KB ~ 100KB）；
单集群或单实例需要支撑 ≥ 50 万 QPS 的高并发；
集群规模 ≥ 100 分片，对拓扑收敛时间与故障切换敏感；

Valkey 在架构与实现层面的优化会拉开与 Redis 的差距。
典型对比数据节选：


大 Key 混合读写（100KB）：

Redis：QPS ≈ 8.2 万，P99 ≈ 15.3ms；
Valkey：QPS ≈ 12.3 万，P99 ≈ 9.8ms；
QPS 提升约 50%，延迟下降约 36%。



高并发连接能力：

Redis：稳定连接数 ≈ 8 万；
Valkey：稳定连接数 ≈ 15 万；



满负载稳定性（CPU 100%）：

Redis：约 4 小时后开始出现 ~0.1% 超时；
Valkey：72 小时压测中未出现超时。



大规模集群拓扑变更收敛时间（100 分片量级）：

Redis（Gossip）：3 ~ 5 分钟；
Valkey（Raft + Gossip）：10 ~ 15 秒。




结论： 在“大 Key + 高并发 + 大集群”场景下，Valkey 在吞吐、延迟、连接数、故障恢复时间等多个指标上都明显优于 Redis 8.x。

4.3 生态与特殊能力


Redis 8.x 优势：

官方工具生态成熟，如 RedisInsight、Redis Stack 等，复杂场景排障体验更好；
一些小众 / 调试类命令兼容度更高。



Valkey 8.x 优势：

BSD 开源许可证，合规边界更简单直接；
原生支持一些面向 AI / 向量检索的能力（在某些版本或发行版中），可减少对 Redis 商业版的依赖；
在大规模集群与高并发场景下，工程化优化更