1
ericls 2016-03-06 04:37:59 +08:00 via iPhone
改写的代码 逃不掉的啊
|
2
ericls 2016-03-06 04:38:38 +08:00 via iPhone
*该写
|
3
yangqi 2016-03-06 05:53:28 +08:00
mysql 数据为什么要用 redis 缓存?实在要放到内存里直接在 mysql 里建内存表就好了啊
|
4
odirus 2016-03-06 09:03:37 +08:00
只要 MySQL 玩得溜,速度性能都非常好。缓存被太多人误用了,动不动都缓存。
|
5
calease 2016-03-06 11:59:24 +08:00
cache 和 DB 作用不同,没法"同步"数据。
程序控制逻辑是正确的做法。 另外 Redis 比 MySQL 在 Lookup 方面快太多了, 讨论哪个好不好没意义。 |
6
virusdefender 2016-03-06 12:00:24 +08:00
这个还是建议在代码逻辑或者 ORM 层面去处理吧
|
7
SlipStupig OP @odirus 这个是是不对的, redis 的查询速度是 mysql 不可比拟的
|
8
SlipStupig OP |
9
calease 2016-03-06 14:01:03 +08:00
@SlipStupig
既然你想要把 MySQL 的数据放进 redis 里, 我默认你把 redis 作为 cache , mysql 作为 DB 使用, 那么 cache 并不需要同步 DB 的数据, cache 只需要 serve 它有的数据就行了, cache 里的数据从哪来是程序控制的。 我哪句也没涉及 redis 到底是不是“数据库” |
10
orvice 2016-03-06 14:09:10 +08:00
代码层控制,缓存一些 select 数据就可以了
|
11
slixurd 2016-03-06 14:14:37 +08:00
居然有人用 Redis 的持久化.....
而且还是把 Redis 当作 Database 而不是 Cache 来用 |
12
soli 2016-03-06 14:55:44 +08:00
写专门的服务去同步;在程序逻辑上实现实时同步。
数据量大了需要考虑增量同步的事儿。 |
13
SlipStupig OP @soli 增量也确实是个问题,目前做法是定时去刷掉 redis 的数据,并不是一个很好的选择
|
14
yangqi 2016-03-06 23:24:37 +08:00
@SlipStupig redis 和 mysql 完全不同的使用场景, redis 是 in-memory data structure store 。而 mysql 是 RDBMS, 两个根本不是一个重量级的,不能单纯的只比较查询速度。
就和楼上说的,你对 redis 持久化没信心就应该以 mysql 为主, redis 在前面做 cache ,两个不可能百分百同步的, cache 肯定会有 miss 掉的 |
15
yinhexi 2016-09-06 17:40:20 +08:00
看业务实时情景,如果减少业务的代码控制内存,可以使用 canal 搭配队列来做缓存的更新。 canal 监控数据库的变动,如果数据库有任何的变动,直接通过一个后台程序来更新缓存数据。
|