Peter (Peter) · 回帖

请教。怎么推广一个 gem 呢？我的一个 gem s_matix 是有什么硬伤让其不容易被收录和推荐呢？ at 2025年05月20日

粗略看了一下，是个用 map 和 vector 的轮子，CRUD 只实现了 C, 目的是为了解决 Ruby String 对象的内存占用问题，特别是重复对象和空值。

所以 Readme 中提到的 480MB 的 Ruby 内存占用我不知道你是不是用了 freeze 或 # frozen_string_literal: true, 另外，Ruby 3.4 默认设置了 frozen_string_literal 为 true, 如果你有 1440000 个字符串，可以升级 Ruby 看一下内存占用。

你的 gem 在我看来只适合你的特定场景，一个健壮的 rails 系统要尽量减少 gem, 如果内存溢出，得排查老半天，如果不是自己写的 gem, 灾难程度还要升级。

因为内存的特性，内存中的数据只适合做缓存，如果真要在本地用几百 MB 的缓存，我可以在本地装个 Redis 就可以了，Redis 默认还有持久化，速度也能保证。当然，我最先会考虑 ActiveSupport::Cache::MemoryStore, Redis 都不会装。

MemoryStore 的 ruby 对象设计也很优雅，内存限制内不会被清理，超过设定值后，最久未使用（LRU）项会被清理。现在内存这么便宜，我在欧洲 OVH 16 欧元/月的服务器都是 64 GB 内存，为什么还要折腾代码？

AI 歌曲生成器 at 2025年05月18日

打开看到的好像是西班牙语，还没办法切换。学乔布斯做减法？是不是有点过了？

请教。怎么推广一个 gem 呢？我的一个 gem s_matix 是有什么硬伤让其不容易被收录和推荐呢？ at 2025年05月18日

ActiveSupport::Cache::MemoryStore 已经实现了这个功能。Ruby 现在几乎等同于 Rails, 所以用不到你这个 Gem 吧。

今天开源一个博客引擎，助您使用 Markdown 和 Git 进行博客写作 at 2025年04月20日

css 挂了

2024 年了，我还在用薄荷 18 年分享的 10 条最差实践建功立业😂 at 2024年12月21日

Rails 这边是 unique 的，数据库 migration 那边应该同时加上约束吧。擦皮鞋哪有只擦一只的道理，只擦一只鞋不应该过 Pull request。

有些高并发并且不要求 unique 的情况下，也可能造成数据混乱，比如要求只能一个 worker 处理一个对象的数据，但 workers 从一个任务池拿任务时，有可能多个 workers 先后拿到同一个对象不同的耗时任务，因为这个对象可能前前后后有很多任务，这时候用最简单的 advisory_lock 就可以避免了，可以用对象的 id 做锁的 key。

https://dev.mysql.com/doc/refman/9.1/en/locking-functions.html

任务开始的时候用 IS_FREE_LOCK('#{id}') 查一下，如果 free 就 get_advisory_lock, 最后 ensure 一下 release_advisory_lock

ActiveRecord::Base.connection.get_advisory_lock(id)
ActiveRecord::Base.connection.release_advisory_lock(id)

这样就保证了只有一个 worker 能处理这个耗时任务，其它的 works 拿到这个对象的任务时，要把这个任务放回任务池。

https://apidock.com/rails/ActiveRecord/ConnectionAdapters/AbstractAdapter/get_advisory_lock

2024 年了，我还在用薄荷 18 年分享的 10 条最差实践建功立业😂 at 2024年12月12日

Quote: “如果不是经常更新的内容，比如首页的 Banner 和广告这类首页接口，并发量最大，而且更新少”

常更新的也没有问题，设置好过期时间就行了，一小时更新一次，一天也就 24 次，虽然每个 puma 进程都管理自己的 cache，比如说有 8 个 puma 进程，同一个缓存就要重复保存 8 次，那一天也只更新 24*8 = 192 次，但现在内存这么便宜，数据库又放在 ssd 上，不用太在乎。

Rails 官方的文档不建议在生产环境中使用 MemoryStore 是因为多进程或多服务器之间不能共享缓存，另外就是上面说的会浪费内存。理解了原因就可以打破规则了。

我经手的一个生产环境的 k8s 里有十几台 64GB 的 rails 服务器，直接配置的 MemoryStore 作为 Cache, 再用另外的全局变量 redis_client 连接 Redis cluster 用来处理经常变动 (1 小时以下，一般是分钟以下，秒级别) 的缓存，目前运行得非常稳。

对于那种又大又不定期更新的缓存，还希望能在各进程和服务器间同步更新，并且不希望把这么大的缓存存在 redis，也有办法：

例如把 Category.all 保存在 MemoryStore 的 :categories_cache 中，永不过期，另外再把缓存生成的时间保存在 :categories_lazy_updated_at 中，永不过期。
在更新 model 的同时，用 after_save 钩子在 Redis 中更新一个对应的键 categories_redis_updated_at，值就是当下的 timestamp，在各个服务器每个进程中的 MemoryStore 缓存这个 Redis 的键值对，键名 :categories_eager_updated_at，过期时间一分钟或你期望的间隔。
每次读取 :categories_cache 时都比较 :categories_lazy_updated_at 和 :categories_eager_updated_at 的值，这个过程都在本地，时间忽略不计，如果前者小于后者，说明 Category 已经更新了，那重新生成缓存 :category_cache，再把 :categories_lazy_updated_at 的值更新为 categories_eager_updated_at 的值，其实也是categories_redis_updated_at 的值。

这样在 Redis 中只用了一个 timestamp 就在极小的间隔同步了各个进程和各个服务器之间的缓存更新。如果有多个这样的缓存，还可以优化，比如把多个缓存的 timestamps 组成一个 hash 放在 Redis 的一个键中。我最后还做了一个页面，所有的缓存都一目了然，包括值，占用空间大小，过期时间，当然页面中的本地缓存只是某一台服务器中某一个 puma 进程中的值