学习任何新知识，都是一个循序渐进的过程，从刚开始的懵懂无知，到简单熟悉，然后突然的彻悟，成果让人欣喜若狂，心情也会快乐很久。
redis+mysql和内存+硬盘类似的地方
首先看图：
首先，我们知道，mysql是持久化存储，存放在磁盘里面，检索的话，会涉及到一定的IO，为了解决这个瓶颈，于是出现了缓存，比如现在用的最多的memcached(简称mc)。首先，用户访问mc，如果未命中，就去访问mysql，之后像内存和硬盘一样，把数据复制到mc一部分。
redis和mc都是缓存，并且都是驻留在内存中运行的，这大大提升了高数据量web访问的访问速度。然而mc只是提供了简单的数据结构，比如string存储；redis却提供了大量的数据结构，比如string、list、set、hashset、sorted set这些，这使得用户方便了好多，毕竟封装了一层实用的功能，同时实现了同样的效果，当然用redis而慢慢舍弃mc。
内存和硬盘的关系，硬盘放置主体数据用于持久化存储，而内存则是当前运行的那部分数据，CPU访问内存而不是磁盘，这大大提升了运行的速度，当然这是基于程序的局部化访问原理。
推理到redis+mysql，它是内存+磁盘关系的一个映射，mysql放在磁盘，redis放在内存，这样的话，web应用每次只访问redis，如果没有找到的数据，才去访问Mysql。
然而redis+mysql和内存+磁盘的用法最好是不同的。
redis+mysql和内存+硬盘运行模式是不同的
了解过内存和硬盘运行过程的同学，都知道他俩之间通过页面置换算法进行调度，也就是说每次是按块将数据从硬盘换入或者换出内存，比如硬盘有一个100G的文件，如果要读这个文件，内存中每次只放该文件10MB的一部分（图1中的小块就是这个意思）。
于是有人会猜测，mysql存储了100G的数据，用户访问mysql的时候，把10MB数据拷贝到redis，比如select一个id=1000的数据，那就把id=10到id=9999的数据放到redis，用于下次访问。可是关键在于mysql数据的访问，并不是文件这种局部性原理，不同的用户访问的是完全不同的东西，跟id的次序没有任何关系。
其实redis的强项也不在此，它擅长保存元数据类的数据，也就是说描述性的而不是数据本身
就此我假定了redis的几个应用场景，请大家批评指正：
存放计数器的数字
存放检索关键词的id列表（不放内容）
存放用户之间的follow关系（非用户信息）
存放简单的静态Html，而非所有的CSS和JS
总之发现，就是redis大量存放的是数据表的索引字段，如果刚好用到符合条件的信息，可以根据索引字段，再去mysql查找，比如搜索关键词”redis”，第一步我们去mysql获取redis相关的信息返回给用户，然后记录一个zset，将redis作为名字，将搜索到的每个Id以先后顺序存在里面，那么下次有人搜索”redis”，直接根据该列表去mysql找对应id的信息就行了，这已经大大提升了访问速度。
下图是一个检索的流程图：
由上是关于redis这一段的心得，希望大家批评指正，谢谢使用HAProxy、PHP、Redis和MySQL支撑10亿请求每周架构细节
发表于 10:05|
来源High Scalability|
作者Todd Hoff
摘要：着眼创业公司，应用程序架构主要考虑因素不只是技术，成本效益同样必不可少。因此，对于优秀的架构师，基于遗留系统、已有开发团队，以最小成本构造出可持续应用才是王道。
【编者按】在公司的发展中，保证服务器的可扩展性对于扩大企业的市场需要具有重要作用，因此，这对架构师提出了一定的要求。Octivi联合创始人兼软件架构师Antoni
Orfin将向你介绍一个非常简单的架构，使用HAProxy、PHP、Redis和MySQL就能支撑每周10亿请求。同时，你还能了解项目未来的横向扩展途径及常见的模式。
以下为译文：
在这篇文章中，我将展示一个非常简单的架构，使用HAProxy、PHP、Redis和MySQL支撑每周10亿请求。除此之外，我还将展示项目未来的横向扩展途径及常见的模式，下面我们一起看细节。
3个应用程序节点
2个MySQL+1个备份
应用程序每周处理10亿请求
峰值700请求每秒的单Symfony2实例（平均工作日约550请求每秒）
平均响应时间30毫秒
Varnish，每秒请求超过1.2万次（压力测试过程中获得）
Redis储存了1.6亿记录，数据体积大约100GB，同时它是我们的主要数据存储
MySQL储存了3亿记录，数据体积大约300GB，通常情况下它作为三级缓存层
HAProxy + Keepalived
PHP（PHP-FPM）+ Symfony2 Framework
MySQL（主从配置），使用HAProxy做负载均衡
Redis （主从配置）
大约1年前，一个朋友找到我并提出了一个苛刻的要求：它们是一个飞速发展的电子商务初创公司，而当时已经准备向国际发展。介于那个时候他们仍然是一个创业公司，初始解决方案必须符合所谓的成本效益，因此也就无法在服务器上投入更多的资金。遗留系统使用了标准的LAMP堆栈，因此他们拥有一个强力的PHP开发团队。如果必须引入新技术的话，那么这些技术必须足够简单，不会存在太多架构上的复杂性；那么，他们当下的技术团队就可以对应用进行长期的维护。
为了满足他们扩展到下一个市场的需求，架构师必须使用可扩展理念进行设计。首先，我们审视了他们的基础设施：
老系统使用了单模块化设计思路，底层是一些基于PHP的Web应用程序。这个初创公司有许多所谓的前端网站，它们大多都使用了独立的数据库，并共享了一些支撑业务逻辑的通用代码。毫不客气的说，长期维护这种应用程序绝对是一个噩梦：因为随着业务的发展，有些代码必须被重写，这样的话，修改某个网站将不可避免导致业务逻辑上的不一致，这样一来，他们不得不在所有Web应用程序上做相同的修改。
通常情况下，这该归结于项目管理问题，管理员必须对横跨多个代码库的那些代码负责。基于这个观点，整改第一步就是提取核心的业务关键功能，并将之拆分为独立的服务（这也是本文的一个重点部分），也就是所谓的面向服务架构，在整个系统内遵循“separation
of concern”原则。每个服务只负责一个业务逻辑，同时也要明确更高等级的业务功能。举个形象的例子也就是，这个系统可能是个搜索引擎、一个销售系统等。
前端网站通过REST API与服务交互，响应则基于JSON格式。为了简单起见，我们没有选择SOAP，一个开发者比较无爱的协议，因为谁都不愿意解析一堆的XML。
提取一些不会经常处理的服务，比如身份验证和会话管理。这是非常必要的一个环节，因为它们的处理等级比较高。前端网站负责这个部分，只有它们可以识别用户。这样一来我们可以保持服务的足够简单，在处理扩展和代码相关问题时都具有巨大的优势，可谓各司其职，完美无缺。
带来的好处：
独立子系统（服务）可以便捷的在不同团队中开发，开发者互不干涉，效率理所当然提升。
身份验证和会话不会通过它们来管理，因此它们造成的扩展问题不翼而飞。
业务逻辑被区分，不同的前端网站不会再存在功能冗余。
显著地提高了服务的可用性。
共生的缺点：
为系统管理员带来更大的工作量。鉴于服务都使用了独立的基础设施，这将给管理员带来更多需要关注的地方。
很难保持向后兼容。在一年的维护之后，API方法中发生了数不尽的变化。因此问题发生了，它们必将破坏向后兼容，因为每个网站的代码都可能发生变化，还可能存在许多技术人员同时修改一个网站的情况……然而，一年后，所有方法匹配的仍然是项目开始时建立的文档。
应用程序层
着眼请求工作流，第一层是应用程序。HAProxy负载均衡器、Varnish和Symfony2应用程序都在这一层。来自前端网站的请求首先会传递给HAProxy，随后负载均衡器将把他分给不同的节点。
应用程序节点配置
Xeon E5-GHz，64GB RAM，SATA
PHP 5.4.X（PHP-FPM），使用APC字节码缓存
我们购买了3个这样的服务器，N+1冗余配置的active-active模式，备份服务器同样处理请求。因为性能不是首要因素，我们为每个节点配置独立的Varnish以降低缓存hit，同时也避免了单点故障（SPOF）。在这个项目中，我们更重视可用性。因为一个前端网站服务器中使用了Apache
2，我们保留了这个堆栈。这样一来，管理员不会困扰于太多新加入的技术。
Symfony2应用程序
应用程序本身基于Symfony2建立，这是一个PHP全堆栈框架，提供了大量加速开发的组件。作为基于复杂框架的典型REST服务可能受到很多人质疑，这里为你细说：
对 PHP/Symfony 开发者友好。客户端IT团队由PHP开发者组成，添加新技术将意味必须招聘新的开发者，因为业务系统必须做长时间的维护。
清晰的项目结构。
PHP/Symfony虽然从来都不是必需品，但却是许多项目的默认选择。引入新的开发者将非常方便，因为对他们来说代码非常友好。
许多现成的组件。遵循DRY思想……没有人愿意花力气去做重复的工作，我们也不例外。我们使用了大量的Symfony2 Console
Component，这个框架非常有利于做CLI命令，以及应用程序性能分析（debug工具栏）、记录器等。
在选用Symfony2之前，我们做了大量的性能测试以保证应用程序可以支撑计划流量。我们制定了概念验证，并使用JMeter执行，我们得到了让人满意的结果——每秒700请求时响应时间可以控制在50毫秒。这些测试给了我们足够的信心，让我们坚信，即使Symfony2这样复杂的框架也可以得到理想的性能。
应用程序分析与监控
我们使用Symfony2工具来监视应用程序，在收集指定方法执行时间上表现的非常不错，特别是那些与第三方网络服务交互的操作。这样一来，我们可以发现架构中潜在的弱点，找出应用程序中最耗时的部分。
冗长的日志同样是不可缺少的一部分，我们使用PHP Monolog库把这些日志处理成优雅的log-lines，便于开发者和管理员理解。这里需要注意的是尽可能多地添加细节，越详细越好，我们使用了不同的日志等级：
Debug，可能会发生的事情。比如，请求信息在调用前会传送给一个外部Web服务；事情发生后从API调用响应。
Error，当错误发生时请求流并未被终止，比如第三方API的错误响应。
Critical，应用程序崩溃的瞬间。
因此，你可以清晰地了解Error和Critical信息。而在开发/测试环境中，Debug信息同样被记录。同时，日志被存储在不同的文件中，也就是Monolog库下的“channels”。系统中有一个主日志文件，记录了所有应用程序级错误，以及各个channel的短日志，从单独的文件中记录了来自各个channel的详细日志。
扩展平台的应用程序层并不困难，HAProxy性能并不会在短时间耗尽，唯一需要考虑的就是如何冗余以避免单点故障。因此，当下需要做的只是添加下一个应用程序节点。
我们使用Redis和MySQL存储所有的数据，MySQL更多作为三级缓存层，而Redis则是系统的主要数据存储。
在系统设计时，我们基于以下几点来选择满足计划需求的数据库：
在存储大量数据时不会影响性能，大约2.5亿记录
通常情况下多是基于特定资源的简单GET请求，没有查找及复杂的SELECT操作
在单请求时尽可能多的获得资源以降低延时
在经过一些调查后，我们决定使用Redis
大部分我们执行的操作都具有 O（1）或O（N）复杂性， N是需要检索键的数量，这意味着keyspace大小并不会影响性能。
通常情况下会使用MGET命令行同时检索100个以上的键，这样可以尽可能的避免网络延时，而不是在循环中做多重GET操作。
我们当下拥有两个Redis服务器，使用主从复制模式。这两个节点的配置相同，都是Xeon E5-.60GHz，128GB，SSD。内存限制被设置为100GB，通常情况下使用率都是100%。
在应用程序并没有耗尽单个Redis服务器的所有资源时，从节点主要作作备份使用，用以保证高有效性。如果主节点宕机，我们可以快速的将应用程序切换到从节点。在维护和服务器迁移时，复制同样被执行——转换一个服务器非常简单。
你可能会猜想当Redis资源被一直耗尽时的情景，所有的键都是持久化类型，大约占90% keyspace，剩余资源被全部被用于TTL过期缓存。当下，keyspace已经被分为两个部分：一个是TTL集（缓存），另一个则是用于持久化数据。感谢“volatile-lru”最大化内存设置的可行性，最不经常使用缓存键会被移除。如此一来，系统就可以一直保持单Redis实例同时执行两个操作——主存储和通用缓存。
使用这个模式必须一直监视“期满”键的数量：
db.redis1:6379& info keyspace
# Keyspace
db0:keys=16XXXXXXX,expires=11XXXXXX,avg_ttl=0
“期满”键数量越接近0情况越危险，这个时候管理员就需要考虑适当的分片或者是增加内存。
我们如何进行监控？这里使用Icinga check，仪表盘会显示数字是否会达到临界点，我们还使用了Redis来可视化“丢失键”的比率。
在一年后，我们已经爱上了Redis，它从未让我们失望，这一年系统从未发生任何宕机情况。
在Redis之外，我们还使用了传统RDBMS——MySQL。但是区别于他人，我们通常使用它作为三级缓存层。我们使用MySQL存储一些不会经常使用对象以降低Redis的资源使用率，因此它们被放到了硬盘上。这里没有什么可说道的地方，我们只是尽可能地让其保持简单。我们使用了两个MySQL服务器，配置是Xeon
E5-GHz，64GB RAM，SSD。两个服务器使用本地、异步的主-主复制。此外，我们使用一个单独的从节点作为备份。
MySQL的高可用性
在应用程序中，数据库永远是最难的瓶颈。当前，这里还不需要考虑横向扩展操作，我们多是纵向扩展Redis和MySQL服务器。当下这个策略还存在一定的发展空间，Redis运行在一个126GB内存的服务器上，扩展到256GB也并不困难。当然，这样的服务器也存在劣势，比如快照，又或是是简单的启动——Redis服务器启动需要很长的时间。
在纵向扩展失效后进行的必然是横向扩展，值得高兴的是，项目开始时我们就为数据准备了一个易于分片的结构：
在Redis中，我们为记录使用了4个“heavy”类型。基于数据类型，它们可以分片到4个服务器上。我们避免使用哈希分片，而是选择基于记录类型分片。这种情况下，我们仍然可以运行MGET，它始终在一种类型键上执行。
在MySQL上，结构化的表格非常易于向另一台服务器上迁移——同样基于记录类型（表格）。当然，一旦基于记录类型的分片不再奏效，我们将转移至哈希。
学到的知识
不要共享你的数据库。一旦一个前端网站期望切换会话处理到Redis，Redis缓存空间将被耗尽，同时它会拒绝应用程序保存下一个缓存键。这样一来所有的缓存将转至MySQL服务器，这将导致大量开销。
日志越详细越好。如果log-lines中没有足够的信息，快速Debug问题定位将成为难点。如此一来，你不得不等待一个又一个问题发生，直到找到根结所在。
架构中使用复杂的框架并不意味着低性能。许多人惊讶我们使用全堆栈框架来支撑如此流量应用程序，其秘诀在于更聪明的使用工具，否则即使是Node.js也可能变得很慢。选择一个提供良好开发环境的技术，没有人期望使用一堆不友好的工具，这将降低开发团队士气。
原文链接：（翻译/童阳 责编/仲浩）
免费订阅“CSDN云计算（左）和CSDN大数据（右）”微信公众号，实时掌握第一手云中消息，了解最新的大数据进展！
CSDN发布虚拟化、Docker、OpenStack、CloudStack、数据中心等相关云计算资讯， & & 分享Hadoop、Spark、NoSQL/NewSQL、HBase、Impala、内存计算、流计算、机器学习和智能算法等相关大数据观点，提供云计算和大数据技术、平台、实践和产业信息等服务。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章redis 本身有持久化，为什么还要写进 mysql 呢？ - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
redis 本身有持久化，为什么还要写进 mysql 呢？
09:34:10 +08:00 · 14426 次点击
redis 本身的持久化做得挺靠谱的，为什么还要多一个定时任务来写进 mysql?
如果是因为防止恶意攻击被 flush 的话， mysql 也不大可能会幸免啊。
59 回复 &| &直到
14:31:43 +08:00
& & 09:36:26 +08:00
思维固化吧。
总提心吊胆的觉得 mysql 才是持久之道， redis 只能做 cache
& & 09:39:02 +08:00
可能为了以后清 cache 吧。
& & 09:43:57 +08:00
& & 09:47:02 +08:00
感觉是不是为了某些特定的数据持久化？
& & 09:53:03 +08:00
当然也可以不写入，写入的好处肯定更多，有时候会有各种需求还是基于 mysql 更方便
比如统计数据分析数据使用 mysql 更方便
& & 09:55:59 +08:00
思维固化+1 redis 的持久化还是很好用的。
& & 09:57:49 +08:00
我觉得不是思维固化。。也有一定的原因，毕竟新浪那些工程师也不是不知道这些。坐等大侠前来解答
& & 09:58:35 +08:00
数据安全不是有持久化就好的
& & 10:03:52 +08:00
MySQL 在崩溃处理，数据恢复方面比 redis 要好，
& & 10:04:48 +08:00
redis 作为数据库查询功能太弱了。
& & 10:05:05 +08:00
redis 可以针对某些特定的 key,或者 field 做持久化吗？
& & 10:06:21 +08:00
我觉得是完全可以只用 redis 的，可能还是因为熟悉 mysql 的人比较多吧
& & 10:08:12 +08:00
SQL 查询还是要强大很多吧，简单分析需求可能一个 SQL 就搞定了。还有一种就是如果数据量多了， Redis 会吃满内存，内存爆掉会有丢数据的风险，这时序列化到 MySQL 就是一种解决方案，将一些冷数据从 Redis 转移到 MySQL ，降低 Redis 内存使用。
Redis 的确很强大，但是内存这块吃紧就不好玩了，国人 SSDB 在这块可能好些(题外话)。
& & 10:10:47 +08:00
定时任务写进 mysql 确实感觉很鸡肋啊，实时的异步写入觉得更有意义一些
& & 10:12:30 +08:00
最重要就是 mysql 是 SQL 数据库， redis 重启后数据加载会耗时
& & 10:15:22 +08:00 via Android
Redis 持久存储和内存占用是 1:1 的关系，体会下～
& & 10:19:22 +08:00
是一种冗余的安全机制么？
& & 10:33:39 +08:00
还是要看具体的应用. 比如有人需要 redis 高速处理请求, 然后 sync 到 mysql 做一些 sql 查询.
Redis 的持久化有 rdb 和 append only file
RDB 定时(一般比较长..)刷到磁盘, 丢数据的风险比较大. 当然有些应用是可以忍受这种级别的丢数据的. RDB 加载很快.
Append only file 貌似每秒 fsync 一次, 没看过具体的代码, 不知道开启了对请求处理速度有没有影响.
这个也会丢数据, recover 速度比较慢. 不过大部分情况下开启 aof 就够用了. 除非有 sql 查询的需求.
以前我设计开发过一个 key-value DB, 丢数据 /性能权衡的问题非常麻烦...
上面的都是根据比较老的版本的, 新版本可能有更多的功能.
& & 10:37:51 +08:00
kv 的数据可能和你的数据结构不相关
比如你计数, 在 redis 中就是一个 key 不停的累加
但在表里的一行数据, 这个计数就有了其他的属性
当你想做这个属性的统计时, mysql 比 kv 的要方便和直观的多了
& & 10:40:27 +08:00
我们曾经做过一个项目, 广告数据
开始的版本全部存储在 memcached 里面, 当你想查些问题时, 非常烦, 你要一个一个的拼 key 去检查
后期的版本改成 log 文件, 结构化存储, 然后解析入库
好处是非常直观, 找什么数据, cat grep 一下就可以
& & 10:41:54 +08:00
有些数据还是结构化的比较容易使用吧
& & 10:46:57 +08:00
没有人提到事务么?
& & 10:52:18 +08:00
请科普关系型数据库
& & 10:53:59 +08:00
@ 事务+1,明明很多人的主程序就是从 MySQL 读数据的，写进去不是很正常么？
若是把 redis 作为唯一的持久化机制，当然可以不写 MySQL ，只不过你的程序需要另外实现事务而已。这没什么。然而当加上事务以及开启持久化特性之后，这样一个写的过程我觉得可能还不如直接写 MySQL 来得快
& & 11:12:27 +08:00 via iPhone
比如博客网站侧边栏的标签，归档和相关的内容是在缓存里面的吧，不可能是都查询一次。
& & 11:27:32 +08:00
sql 查询，很方便
& & 11:27:38 +08:00
@ “实时的异步写入” 要怎么做呢？求教
& & 11:30:25 +08:00
用 MySQL 落地主要是为了自己后期轻松点。经常有如下场景：
1.同步数据。千万级别的历史数据用 MySQL 直接导出 SQL 给需求方就行了。 Redis 总会麻烦一些。
2.数据分析师经常找你要数据，而且大多数分析软件不支持 Redis ，这个时候你怎么弄？
所以用 MySQL 落地对自己和公司都是有大大的好处。
& & 11:33:00 +08:00
这是一道很好的面试题
& & 11:33:55 +08:00
@ 修改 redis 源码，，以前听说个大牛，一天就搞定了
& & 11:41:04 +08:00
@ 这么牛逼，求学习
& & 12:01:37 +08:00
我觉得 是因为 sql 的方式可以很好的把 项目分表, 去分开, redis 这种给人解决先天性就是 kv 模式 很难去解剖复杂的数据结构
& & 12:06:14 +08:00
redis 的数据存于内存中，如果突然断电的话，服务器 redis 中的内存数据就丢失了，写进 mysql 有确保数据不丢失的安全考虑吧
& & 12:14:47 +08:00
统一回复一下吧：
1. 有朋友提到说 Redis 会吃满内存，从而爆掉。
但一般来说 redis 的使用场景（仅从我的角度来看），是在可能需要频繁读写数据，但该数据又并不太重要或者可能只是用一次时，比如点赞，短信验证等，该类数据的话，如前者，存到 mysql 也并不能减少内存压力啊，短信验证的话，用 redis ，设置 expire ，比 mysql 要更好啊，也不会累积太多数据。
2. 实时异步存储
在实际使用时，还是需要从 redis 里面来获取最新数据啊。
3. redis 重启后数据加载耗时
我在实际使用中， mysql 持久只是担心服务器挂掉从而丢失数据，但这类情况特别少见。这边请有经验的前辈分享一下。什么样的数量级会导致 redis 加载过慢? 而且 redis 重启，肯定还是需要从 mysql 再把数据搞回来，这样的话，速度会比 redis 自身的要快很多吗？
wingoo 提到的，也是我现在遇到的问题，每一次要用到某个数据时，比较麻烦，需要去拼 key 。
但不现拼现 get 的话，数据不一定是最新的啊。
neoblackcap 提到的问题，如果是这种情况的话，完全可以在使用到该数据时，来实时存储啊，否则数据可能不准确。
个人愚见。
& & 12:24:58 +08:00
随便说几点。
1. 权限控制
MySQL 有权限控制，用户可以精确到每个 IP 的每个账户，目标可以精确到每个表的每个操作。
Redis 则是天生设计成完全开放权限，包括完全删除数据库的操作，任何人都可以执行。要么就只能把指令重命名成空的，完全禁止任何人执行。
2. 数据完整
MySQL 的数据库保存在磁盘中，万一崩溃断电，也有数据库日志可以用以完成数据库事务。
MySQL 支持主从备份，所有的写入操作都可以实时发送到异地，哪怕突然机房被核弹轰炸，也不会丢失数据（可能除了最后几条语句）。
Redis 的崩溃……嗯小心数据全丢。
Redis 的 Replication 备份……嗯小心数据全丢。
3. 负载均衡
MySQL 可以单主多从，也可以胆子够大在内网做双主，也可以用 innodb 配合 galera 做集群，每台机器都有一个独立的拷贝，因此服务器之间只要传输写指令即可。
Redis 可以单主多从（然而小心数据全丢），但是不能做多主互联。最多最多只能做 sharding ，也就是每台机器只保存一部分数据，读写一律被分散到其他机器上。直接后果就是内网流量大增。
4. 数据隔离
MySQL 里我可以选择删掉某个应用的所有数据而保留另一个应用的所有数据。
Redis 里要么依赖 11 个 DB 的选择，要么依赖命名空间。
5. 性价比
MySQL 是内存+硬盘，上个 SSD 配合 Query Cache 那速度已经是很快了。
Redis 是纯内存。乖乖掏钱加内存换至强啦。而且你还是得配备高性能磁盘，因为定时刷到磁盘和开机加载数据的操作还是要磁盘性能的。
& & 12:30:47 +08:00 via Android
感觉好像前段时间看过这个帖子
& & 12:36:54 +08:00
可能的问题：
1. redis 的持久化是异步的，出现异常丢数据的概率很高。
2. mysql 可以做复杂的查询。
& & 12:43:06 +08:00
@ 能否说说如何实现?特别是这个定时任务写到 mysql 如何实现?搜索关键词也行....第一次接触 redis 搞的无头绪啊,orz
& & 12:48:40 +08:00
我是做统计的，公司各种统计任务
改写之前的 sql 统计习惯？
不可能的，这个太难了，再说，好不容易学了一些一个 sql 就能解决的统计问题，现在你告诉我，让我全部使用 redis 的规则来写，然后数据处理全部使用编程语言进行
我的思维是固化的
我只知道我统计出来的数据很重要或者不重要，重要的数据为何我要冒险使用可能会有问题，或者自己不熟的操作方式去做，不重要的数据，我为何要写个程序去做？而不是仅仅写一个条嵌套 sql 。
3. 需求不同
开发这样想是对的，但是其他的人可能会面临新的压力，新的技术挑战，所以需求定位是最终的出发点，除非哪天 redis 的统计也能做的很溜
& & 12:49:23 +08:00 via Android
1.持久化不是实时的
2.只能用键查询
& & 13:12:19 +08:00
1 ，突然掉电
2 ，内存出问题
& & 13:32:11 +08:00
MySQL 不只是存储啊，还有 SQL 这样的查询接口...
& & 13:41:58 +08:00
为什么没人提 Redis 的时效时间呢....
& & 14:05:34 +08:00
我阐述一下我的观点，
1.我记得是先有得 memcache , 后推出的 redis , 增加了数据运算功能， hash 和队列等，当时都不支持固化，起点都是提高访问速度，减少数据压力， redis 分析市场需求，尝试推出的本地固化功能，可实际应用中是这样的， 数据会分为热数据和冷数据，或者称为活跃数据和非活跃数据，全都在 redis ，显然长期下来并不合理， redis 的 RDB 快照和 AOF 纪录都会有一定的硬盘负担。关系数据库又是必不可少的，项目中多少都会用， 既然少不了， 索性不如更多的利用起来， redis 可以是一个小硬盘，多内存的专属服务器集群， 专心做缓存。 mysql 专心做存储。（补充， redis 在热数据冷数据的区分上，是支持的，可以将冷数据固化起来，有需要时提取出来， 但作为 key 的值，会一直在内存中。）
2. 没有可靠的先例或者有谁把 redis 本身的固化机制用的很好又不出问题。那在这个前提下， redis 本身在内存崩溃和重启数据恢复复杂且不确定是否数据完整的情况下，过渡依赖 redis 自身固化机制， 是在给上线的项目找麻烦。所以，同上观点， 把数据转储到一个关系数据反而更容易一些。
其实这些都是需求催生的， 所以有了很多类似于 leveldb 这种纯硬盘的 kv 数据库。 redis 的起点是 cache 。
& & 14:43:29 +08:00
redis 相比 mysql 有几个缺点：
1 ，内存占用巨大
2 ，持久化并不一定是实时的，此时掉电或者其他故障可能会有大量的数据丢失
存 mysql 有几个好处:
1 ，内存占用相比 redis 小很多
2 ， mysql 除了存储，还有 sql 这个强大的东西
结论，楼上说什么思维固化，不是这么一回事，我们用东西，要看清楚每一种工具的适用场景，而不是一味的相信新技术就必然好于旧的技术。而是要，遇到什么问题，就用什么工具。说思维固化的那些人，其实他们的思维才真正的固化，做不到灵活的使用手上的工具。
& & 16:08:14 +08:00
& & 17:44:02 +08:00
主要还是方便支持后期的数据整理工作吧，然后相对来说，大家还是更熟悉 sql
& & 18:31:03 +08:00
redis 不支持事务，查询不方便
& & 18:58:54 +08:00
* mysql flush 数据到磁盘也是“异步”的，也会有丢失数据的可能。
首先，数据总有“冷”、“热”之分，前者放在 redis 里显然浪费资源。
其次，性能、成本，最终是一个权衡的问题。举例，有 model ( name, last_updated_at )，需求是通过 name 获取 last_updated_at 。看来放 reds 里面又快又美，但当数据到一定量级时，比如 1 亿、 10 亿条， reds 方案的成本会相当高，而 mysql 方案牺牲一点点性能，可以节省大量成本。
& & 19:03:23 +08:00 via Android
技术还是基于业务的 使用新技术风险比较大 安全稳定才是王道 为了安全稳定花的金钱和时间都是值得的 数据出现一次问题那后果就很大了 我们公司因为北京某银行出现一次故障推荐所有入职员工不要办理这个银行的公积金联名卡
& & 19:22:03 +08:00 via Android
为什么不吃玉米替代主食米饭呢？
redis 能事务么
& & 20:53:52 +08:00
不错的面试题啊~
1. 场景不一样， redis 的持久化是附加功能， mysql 的持久化是核心功能
2. redis 的 flushdb 、 flushall 太犀利了，用 redis 来持久化数据总感觉不靠谱
3. 持久化机制不一样，举个例子来说，当数据量达到 10G 的时候，你改了几条数据， mysql 只增量地持久化这几条数据；而 redis 只知道自己该持久化了，然后把 10G 数据完整地从内存 dump 到磁盘，是不是很过瘾
& & 21:38:50 +08:00
只用 redis 废弃 mysql ，使用的时候确实很爽，突然有需求做个统计或者架构改变做数据迁移就闷逼了
& & 21:45:16 +08:00
3 年前的感想: redis 的持久化,特别是 AOF 一点也不靠谱,对性能影响太大, 开过之后再也不想开了. RDB 会丢数据.
& & 22:02:30 +08:00
redis 的持久化并不靠谱。当然是相对于各种 DB 来说。而且无论是 RDB 还是 AOF 对性能影响都不小，缓存就做好缓存的事情吧。
& & 18:24:25 +08:00
@ 用个异步队列就 OK 了
& & 11:43:44 +08:00
能具体说说当时的场景吗？
@ 用 cron 事件，通过时间，或者根据新增数据的数量。
& & 13:38:46 +08:00
写入 MYSQL 可以进行一些查询和管理界面咯。
& &214 天前
& · & 813 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 71ms · UTC 00:17 · PVG 08:17 · LAX 16:17 · JFK 19:17? Do have faith in what you're doing.