couchbase ttl 设置问题

哈哈，今天打算把这个博客写成流水账。。

今天加班过来公司想解决一个 bug，然后优化一下代码。

但是过来之后就开始学 Scala 相关的东西，一直到了五点才开始想这个 bug。

没想到一分钟就灵关一闪意识到了为什么。。。调查了一下代码果然是这样。。。

可怜自己前两天凌晨 debug 一个多小时。。。可见有了 bug 无需惊慌，不着急的话可以缓缓。

原因是我把在配置文件中设置的 ttl：180（单位为天）没有转换成秒，就写入couchbase 了。所以真实的 ttl 只有 180s。。。

难怪本来应该缓慢增长的数据量会时高时低，观察了一下监控，数据量果然是跟qps曲线相同。。。

前两天debug的时候业务逻辑层面写了一堆 log 也觉得越调查越奇奇怪怪的，为毛数据有时候有有时候没有呢。

然后把写入的程序停掉，心想再过 180s 数据量就会将为 0 了吧！

结果，过了 15 分钟才变为 0 。

咦，奇怪，难道原来数据库中有些数据不是我写的？或者couchbase api 秒级的api只是随便逗你玩呢？

然后就重新写入了 20 条数据。也查了一下 couchbase server 的文档。

http://docs.couchbase.com/developer/dev-guide-3.0/doc-expiration.html

文档表示

Couchbase Server does lazy expiration, that is, expired items are flagged as deleted rather than being immediately erased. Couchbase Server has a maintenance process, called the expiry pager that periodically looks through all information and erases expired items. This maintenance process runs every 60 minutes, but it can be configured to run at a different interval. Couchbase Server immediately removes an item flagged for deletion the next time the item is requested and the server responds to the requesting process with a message indicating that the item does not exist.

人家只是标记删除，真正从数据库中删除要 expiry pager 程序定期执行的哦，默认 60 分钟一次。

然而，你如果请求了一个已经被标记删除的item，这次请求也会触发数据库真正删除掉这个 item.

然后监控程序应该就是不管是否被标记删除了的，展示给用户的是数据库中的条目数目。

我试了一下果然是这样，10分钟后访问一个被删掉的 id，果然取不到数据了。然后监控也立刻从 20 条变成了 19 条。

剩余的 19 条过了几十分钟就被批量清除啦。

但是今天还要不要优化代码呢  ：（