@poshboytl @chairy11 这种用算法生成唯一序列，在极端情况下也是有碰撞概率的，不过一般情况下都是够用的。我说的就是 @diguage 这种方式，用数据库的自增性和唯一性再加一些自定义规则来保证全局唯一性。

#4 楼 @nouse @chairy11 我也推荐用数据库生成，唯一性和自增特性，加上一些额外的规则可以保证。其他方式，并发的情况下都比较难保证。

@seller.user_info_token = loop do
    token = SecureRandom.urlsafe_base64
    break token unless User.exists?(user_info_token: token)
  end
  @seller.user_info_token = SecureRandom.uuid

并发情况下，两个 thread 同时生产相同的 user_info_token，是都会保存成功的。

@rei 要不要加一个收藏回复的功能呢？

要定义三个方法，也是醉了，要实现同样的功能可能要写很多重复代码。而且 Ruby 也不会写那么啰嗦的。

在之前，我一般是用 SQL 先把要修改的表结构先处理好

我想知道是怎么处理的？

组件里全部使用 props，只在顶层组件里使用 state。

这点不错。

同 hooopo，看起来整齐的情况下会写。

:plus1:

另外像 Unicorn 这样 每个进程同时只能处理一个请求（one process per request），不仅仅是极度的浪费，而且如果某一个 action 突然变慢 将会占满整个 worker poll。导致整个服务都不可用。

为什么不考虑换线程服务器比如 puma。

em 常年不更新也变成一个坑了。

#29 楼 @shawnyu 如果多数任务是三方服务，用 EventMachine 应该也比较快的。

#35 楼 @shawnyu 这个 go-worker 的并发量是多少呢？

#15 楼 @lips 赵劼

再推荐一个 git-up

12 台 8 核 16G 机器 跑 sidekiq 的任务

我想知道有多少任务在跑。

要注明出处，这篇是 rubyweekly 推荐的。

求 http://coolshell.cn/ 和 赵姐夫

等了太久 :plus1:

我觉得可能是作者写错了吧。

@yesmeck

#1 楼 @tiseheaini

返回结果肯定是数组了。

坐标呢？

围观

妹子好多。

理论上会丢。

#51 楼 @qhwa

Reids 有备份到磁盘的机制，当频繁触发这个这个的时候，会连续写到硬盘，这个时候磁盘的 IO 会暴增，而且内存也会用到很多。把这个触发机制修改下就好了。比如原来的 1 秒写入 60000 次会备份到硬盘改为 3 秒 600000 次。这个问题我们以前遇到过，当时就是这样解决的。

还有就是不知道appendonly yes不知道有没有影响。

不错！

Comparison:
LruRedux::ThreadSafeCache:   337353.5 i/s
ActiveSupport::Cache::MemoryStore:    52808.1 i/s - 6.39x slower
ActiveSupport::Cache::FileStore:    12341.5 i/s - 27.33x slower
ActiveSupport::Cache::DalliStore:     6629.1 i/s - 50.89x slower
ActiveSupport::Cache::RedisStore:     6304.6 i/s - 53.51x slower
ActiveSupport::Cache::DalliStore at pub-memcache-13640.us-east-1-1.2.ec2.garantiadata.com:13640:       26.9 i/s - 12545.27x slower
ActiveSupport::Cache::RedisStore at pub-redis-11469.us-east-1-4.2.ec2.garantiadata.com:       25.8 i/s - 13062.87x slower

@billy @lgn21st @kgen 但是这是这篇博客的结果，单机上 FileStore 甚至比 memcached 和 redis 快，当时也是注意到这点。

文章里面关于每个缓存的优势和劣势都讲解的比较清楚，如果只是单机的话： FileStore: Advantages:

• Disk space is cheaper than RAM Disadvantages:
• Not an LRU cache

When should I use ActiveSupport::FileStore? Reach for FileStore if you have low request load (1 or 2 servers) and still need a very large cache (>100MB). Also, don't use it on Heroku.

Memcache and dalli: Disadvantages：

• Expensive.
• Cache values are limited to 1MB.

Redis and redis-store: Advantages:

• Allows different eviction policies beyond LRU
• Can persist to disk, allowing hot restarts

Disadvantages:

• Expensive
• While Redis supports several data types, redis-store only supports Strings

LRURedux: Advantages:

• Ridiculously fast

Disadvantages:

• Caches can't be shared across processes or hosts
• Caches add to your total RAM usage
• Can't use it as a Rails cache store

其实 Memcache/Redis，对比来看，两个无论是性能还是特性在单机上都差不是太多，甚至有网络访问，需要多机器是也差不多。相比而言 Redis 还有比较好的缓存实效时间的设置和热备份机制。所以这两个来选可以选 Redis。

对比 FileStore 来看，虽然从理论上讲访问硬盘肯定要比访问内存慢，但是文章中的测试结果是，访问文件系统更快，这点我也比较有疑问。不过比较好的地方就是 FileStore 比较廉价，不好的地方就是没有 LRU。

如果楼主有比较大的内容需要缓存并且内存吃紧，可以用 FileStore 缓存来处理，但是记得自己清除缓存就好了。Redis 的话，比较方便的是缓存的生命周期可以设置。

其实我觉得这个 LRURedux 也不错，这变态的性能也让人跃跃欲试。不过就是缺点也挺多，Caches can't be shared across processes or hosts，感觉有点像 MemoryStore。

楼主可以 FileStore 做大文件的缓存，然后同时可以用 Redis-objects 存一些数据，然后同时使用 LRURedux 来做一些小片段的缓存，要注意的是这货和 MemoryStore 一样不能 processes 之间共享。😄

1，用同一个缓存数据库和应用数据库。业务太大再考虑集群。 2，用云存储保存文件。

Ruby 开发现在还差两名。有兴趣的可以来试试。最好有 blog，github，stackvoerflow 的账号或者代码。

典型的消息队列问题。。。