这是 Memcached 中列表的可行解决方案吗？
基本上，我们有销售人员要求致电。现在它尝试通过“新鲜线索”查询来获取这些信息。
如果没有任何新的线索，它将转向“相对新”的查询。我们将这些称为“消息来源”，本质上，终结者将仔细检查消息来源，直到找到可行的线索。
这些查询都查询同一张表，只是查询不同组的数据。然而，每个查询都有很多复杂的排序，在查询和插入/更新表（表是 InnoDB）之间，我们经历了很多等待（我很确定没有死锁，因为它们没有在 InnoDB 中显示） status）所以我的猜测是我们的选择很慢，加上大量的插入/更新。
现在，最终的问题是：
我们是否应该在数据库中查询每个源并获取大约 100 个（显然取决于系统的变量）并将它们缓存在 memcached 中。然后，随着关闭请求的引导，从缓存发送它们，但更新缓存以反映“is_acccepted”标志。这样，当我们用完缓存的线索时，我们只调用每个来源，所以当我们用完时，只调用一次，而不是每个请求线索的关闭者调用一次？
然后我们可以使用 memcached 进行模拟锁定 - http://code.google.com/ p/memcached/wiki/FAQ#Emulated_locking_with_the_add_command
这看起来是一个可行的解决方案吗？有什么建议吗？我们需要最大限度地减少拼命而快速的锁等待的机会。
Basically we have sales people that request leads to call. Right now it tried a "fresh lead" query to get those.
If there aren't any fresh leads it moves on to a "relatively new" query. We call these "sources" and essentially a closer will go through sources until they find a viable lead.
These queries all query the same table, just different groups of data. However, there is a lot of complex sorting on each query and between that and inserts/updates to the table (table being InnoDB) we're experience lots of waits (no deadlocks i'm pretty sure since they don't show in InnoDB status) so my guess is we have slow selects, coupled with lots of inserts/updates.
NOW, the ultimate question IS:
Should we query the DB for each source and grab about 100ish (obviously variable depending on the system) and cache them in memcached. Then, as closers request leads, send them from cache but update the cache to reflect an "is_acccepted" flag. This way we only call each source as we run out of cached leads so just once as we run out, instead of once per closer requesting a lead?
Then we can use simulated locking with memcached - http://code.google.com/p/memcached/wiki/FAQ#Emulating_locking_with_the_add_command
Does this seem like a viable solution? Any recommendations? We need to minimize the chances of lock waits desperately and quickly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来可行，但是您是否查看过索引并且是否在选择上使用了适当的隔离级别？
上一个SO问题可能有助于您寻求的答案： 有什么方法可以在不导致MySQL锁定的情况下进行选择吗？
如果您在具有完整事务的SP中执行选择/更新，这也可以由于优化而大大加快速度。当然，有时 MySQL 中的 SP 会慢得多:(
我已经把它作为评论了，但还没有达到那个水平:)
我确实阅读了有关 inno-db 的部分，但经验表明使用隔离级别时，即使使用 inno，我也能得到改进。
Sounds viable, but have you looked at your indexes and are you using proper isolation levels on your selects?
Previous SO question may help with the answer your seeking: Any way to select without causing locking in MySQL?
If you perform your select/update in a SP with full transaction's this could also speed things up quite a bit due to optimization. Of course, there are times when SP's in MySQL are much slower :(
I'd have put this as a comment, but haven't reached that level yet :)
And I did read the part about inno-db, but experience has shown me improvements even with inno when using isolation levels.
在使用另一个数据存储之前，您绝对应该考虑确保您的数据库查询已完全优化。
如果您确实决定缓存此数据，请考虑使用 Redis，它使列表成为一等公民。
You should definitely look at making sure your DB queries are fully optimized before you employ another datastore.
If you do decide to cache this data then consider using Redis, which makes lists first class citizens.