存档

2017年6月 的存档

RedisCluster数据覆盖问题

2017年6月28日 没有评论

碰到一个典型的问题:
redis的set数据,有大量的读redis和少量的写源(同时删除redis中对应的key),在读的时候做miss回源。

碰到的问题:
少量写后删除key,会同时有大量的读去回源,源压力暴涨,且导致了多次写。回源越慢,源的压力就越大。

计划由读miss回源改为写时覆盖,问题是:set好像没办法覆盖,只能先删除key后再加,删除key时,还是会引发读回源。

看到redis支持rename,就想到一个办法:
少量写的时候,先把数据写到一个新key里,然后rename成老key,从命令上看是支持覆盖的:https://redis.io/commands/rename

RENAME key newkey

Available since 1.0.0.
Time complexity: O(1)
Renames key to newkey. It returns an error when key does not exist. If newkey already exists it is overwritten, when this happens RENAME executes an implicit DEL operation, so if the deleted key contains a very big value it may cause high latency even if RENAME itself is usually a constant-time operation.
Note: Before Redis 3.2.0, an error is returned if source and destination names are the same.
Return value
Simple string reply

Examples
redis> SET mykey "Hello"
"OK"
redis> RENAME mykey myotherkey
"OK"
redis> GET myotherkey
"Hello"
redis> 

结果是出错:

>rename newkey oldkey
(error) CROSSSLOT Keys in request don't hash to the same slot

更多内容…

分类: 工作 标签: , , , ,

MySQL的统计数值问题

2017年6月22日 没有评论

典型的明细与统计数值表问题:
以用户好友关系系统举例:用户的好友有个明细列表,还有一个用户好友个统计数值,便于直接返回好友数,不用每次都count。

问题:
如果增减好友时,用++或–来操作统计值表,容易出现不一致的情况,而且会一直错下去。

解决方案:
更新统计数值的时候,不是+1或-1,而且count后更新。

看似解决了问题,实际上带来了新的问题:
当用户数不多的时候,比如几百或几千,效率很高。但当好友数达到百万时,每次count会耗时两三秒,数据库的负载就会出现严重问题。

最终的解决方案:
当好友数在万以下时,采用count更新;过万以后,用+1或-1来操作。
因为当好友超过一万以后,已经没法人工去数了。有误差也不会影响体验了。

分类: 工作 标签: ,

一种快速失败机制的应用

2017年6月21日 没有评论

描述一下之前的痛点:
一个取列表的功能,QPS近万,当带登录态的时候,需多取下来当前用户发布且未审核过的内容,未审核过的概率非常小,万分之一。
验用户态的响应时间有波动,导致取列表功能受影响。

问题解决思路:
用户票的过期时间比较久,本地验票加一层缓存,miss后回源验票。一段时间后,发现这种miss后回源时,受验票服务的波动影响也很大。
然后引入另一种策略:miss时,直接以无身份状态走,异步验票,成功后记入缓存。

最后扩展到全平台:
非必须登录的功能验票时,都采用这个机制。一般是一些客态的查询功能来支持这种方式。
其它的非查询或主态查询(类似于我的***功能),都强制同步验票。

分类: 工作 标签: