• 进程死锁 at 2018年06月08日

    已感受到被死锁支配的恐惧。。

  • 浅谈尾递归 at 2018年06月06日

    Ruby 的尾递归优化选项，可以局部开启，比如可以针对某个方法单独开启的

  • 丢失的 Ruby 语言参考，英文版 at 2018年05月04日

    思恋的？

  • GraalVM 1.0.0-rc1 released! at 2018年04月18日

    比 JRuby 好在哪？

  • Ruby 应用服务器的新选择 - Nginx Unit at 2018年03月30日

    看起来还不错，但是如果没有为 Ruby 做单独的性能优化，估计还是不如 puma

  • 当年 GitHub 送你们的 3 万元还在吗？ at 2018年01月01日

    帐号密码忘了😂

  • Ruby on Rails 开发的 API，能支撑多大的日请求量？ at 2017年12月12日

    谈日请求量没啥意义吧？如果这一天千万级别请求集中在一秒，那谁也吃不消，如果平均分散的话，那还是很容的

  • 一键把你的 Java ,Go, PHP , Node/JavaScript, Python , Ruby, Julia 函数变成一个服务 at 2017年12月11日

    这种服务一般是什么应用场景需要？

  • Hello, Faktory at 2017年11月24日

    Redis 的 RDB 和 AOF 两种持久化方式都是有延迟的，也就说如果遇到极端情况，比如突然断电是很有可能丢数据的，而 RocksDB 则没有这个问题。

    个人认为 RocksDB 可能比 Redis 更适合这个应用场景，理由：

    1. RocksDB 占用内存更低。虽然读取慢，但既然都是异步任务，应该是不太在乎实时性了。还有就是如果 woker 挂了，大量任务涌进，很有可能导致 Redis 占用内存暴增
    2. RocksDB 数据可靠性更强。Redis 从设计上就没有过多考虑数据的持久化问题
    3. RocksDB 更容易 embedded

    其实成熟的消息队列已经很多了，不知道为什么要造轮子，比如 RabbitMQ 等，AMQP 协议各个语言都有实现，轻松跨语言做 worker

  • Hello, Faktory at 2017年11月24日

    仔细看了一下，Faktory 是内置了 RocksDB 来做消息存储的，RocksDB 在数据可靠性方面应该是比 Redis 好，但是要做 HA 集群的话，就不好说了