请问下为什么弃用了resty.lock而使用了abtesting.utils.sema about abtestinggateway HOT 5 OPEN

• lua-resty-sema的效率要比resty-lock高一些，因为前者是luajit ffi在nginx worker内部实现的，不涉及系统调用和io读写，而后者是通过在ngx-shm维护一个key实现锁的，虽然也不涉及系统调用和io读写，但还是要比sema少很多内存的读写的，而且在nginx配置文件中需要额外配置。
• lua-resty-sema有个缺点是只能在worker内生效，而对于跨进程的shdict来说，这个锁并不那么牢靠；之所以选择sema是因为我不想让所有worker都hang在一个锁上，对于缓存中的一致性倒要求没那么高，同时用来防止所有用户请求同时访问redis，造成性能下降；下一步我计划逐步取消缓存，直接将分流策略和运行时信息写在lua table中，缓存在lru cache里，每次在lua空间里进行计算处理
• abtest有两处锁操作，一处是获取运行时信息，一处是获取upstream，锁的出现可以阻止当缓存失效时所有请求都请求redis或者其他后端存储；使用cache可以避免这样的问题，而且是极大避免

from abtestinggateway.

@BG2BKK 非常感谢你的回复，大致了解了，ABTestingGateway 是一个很棒的项目，也期待项目更多的玩法。

from abtestinggateway.

感谢肯定
项目是否很棒，得进一步看实际使用中的情况，我们在努力

from abtestinggateway.

hi，项目中的iprange等策略，根据客户端的ip进行分流，这可能带来一个问题：客户在北京时，分流到A版本的服务，而第二天出差到了B地，可能被分流到了B版本，这可能会给客户带来困惑，一会A版本，一会B版本。 不知道你们是否有考虑过这个问题呢？

from abtestinggateway.

这个问题比较现实，我们考虑的情况是，比如A地是北京联通，而B地是广东联通，我们在服务端获取的是两地联通的出口IP，这样我们获得IP之后，可以将服务分流到就近节点，起到加速的作用；如果没有这样的分流，很可能在B地仍然访问北京的节点，速度回很慢。

一会A版本，一会B版本，这里需要考虑控制灰度版本之间的差异，就要看具体的使用了。

2016-05-14 16:19 GMT+08:00 daoqidelv [email protected]:

hi，项目中的iprange等策略，根据客户端的ip进行分流，这可能带来一个问题：客户在北京时，分流到A版本的服务，而第二天出差到了B地，可能被分流到了B版本，这可能会给客户带来困惑，一会A版本，一会B版本。
不知道你们是否有考虑过这个问题呢？

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#26 (comment)

黄振栋
[email protected]
Phone：15019477872
AD：广东省深圳市西丽大学城哈工大校区C305B

from abtestinggateway.