高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后,系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
高并发系统设计40问
登录|注册

11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?

唐扬 2019-10-11
你好,我是唐扬。
前几节课,我带你了解了在你的垂直电商项目中,如何将传统的关系型数据库改造成分布式存储服务,以抵抗高并发和大流量的冲击。
对于存储服务来说,我们一般会从两个方面对它做改造:
1. 提升它的读写性能,尤其是读性能,因为我们面对的多是一些读多写少的产品。比方说,你离不开的微信朋友圈、微博和淘宝,都是查询 QPS 远远大于写入 QPS。
2. 增强它在存储上的扩展能力,从而应对大数据量的存储需求。
我之前带你学习的读写分离和分库分表就是从这两方面出发,改造传统的关系型数据库的,但仍有一些问题无法解决。
比如,在微博项目中关系的数据量达到了千亿,那么即使分隔成 1024 个库表,每张表的数据量也达到了亿级别,并且关系的数据量还在以极快的速度增加,即使你分隔成再多的库表,数据量也会很快增加到瓶颈。这个问题用传统数据库很难根本解决,因为它在扩展性方面是很弱的,这时,就可以利用 NoSQL,因为它有着天生分布式的能力,能够提供优秀的读写性能,可以很好地补充传统关系型数据库的短板。那么它是如何做到的呢?
这节课,我就还是以你的垂直电商系统为例,带你掌握如何用 NoSQL 数据库和关系型数据库互补,共同承担高并发和大流量的冲击。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(38)

  • Richeir 置顶
    这一节学到了很多新东西,感谢唐老师的总结!
    2019-10-11
    4
  • jiangjing
    希望可以深入讲解nosql的业务使用场景,比如微博用户关系具体如何使用,模型定义。尤其是该使用场景,如何做到关系数据库不好实现的功能
    2019-10-12
    9
  • Lion
    我们正有这些痛点,思路不错,能更深入一些就更好了!
    2019-10-11
    1
    8
  • 无形
    之前在讲座业务重构中,用es查询数据,其他组的小伙伴维护的es,但是es性能不行,where条件里七八个字段,排序两个字段,查询es基本两千左右QPS,难以支撑支撑十几万人的直播讲座,而且直播人数增长很快,es已经成为了性能瓶颈,查询条件是类标签的,比如几年级,哪个学科,直播类型,还有时间类的,对于这些字段我是可以打标签的,还有开始时间、结束时间,根据类标签的查询特点,我使用了倒排索引+ roaring bitmap 来过滤,使用快速排序对多字段进行排序。使用类延时队列来完成时间的检索。整个检索过程在微秒级,而且对查询的结果做了缓存,查询条件相同的直接从缓存中取,避免了重复检索和排序,查询缓存会在讲座下次修改,更新倒排索引之后清空。重建查询缓存。重构完讲座的检索性能达到了几十倍的性能提升

    作者回复: 👍👍👍

    2019-11-01
    5
    4
  • jc9090kkk
    感谢老师分享,对于文中的知识点有一些疑问,希望老师能解答下:
    1.采用LSM树的nosql,跟mysql的WAL机制类似,mysql通过redo log和bin log的两阶段提交来保证数据的crash-safe,那么nosql的日志是用来做什么呢?也是为了做数据恢复的吗?
    2.像Hbase这样的nosql,涉及的初衷应该是为了做统计而设计的,它支持事务吗?如果支持的话,使用场景是什么?事务的隔离级别都有哪些?因为以我的理解,统计业务,基本都是读请求,很少有写请求,用事务的场景应该极少吧?
    3.因为nosql相比传统的关系型数据库来说,拓展性更好,那么就更适合做分布式系统?后期老师有想法讲一讲比如类似redis或者mongoDB这样的系统,分布式系统的一些实际经验或者说踩过什么坑么?很想了解下。。。

    思考问题:
    公司现在用的nosql包括Redis,ES,Kafka,ClickHouse,采用Redis是用来做cache和秒杀活动,也会有一些异步化的处理,采用Kafka+ES是一是为了采集业务端用户行为,二是ES+Kibana可以提供可视化的数据分析平台供运营部门使用,而且ES在后期的水平拓展的方案上来讲配置和维护比较简单(相比Sphinx而言),为什么采用是因为公司之前接的是第三方的数据统计平台,后期发现统计需要单独定制而且会污染业务代码不好维护,而且有时候会发现数据日志还有丢失的情况导致数据统计异常,所以采用Kafka+ES一起来支撑,从而将业务端的一些耦合较重的埋点逻辑分离出去便于维护,CLickHouse主要是为了生成一些离线的数据报表。

    作者回复: 1. LSM使用WAL也是为了恢复memtable的数据的
    2. 是不涉及事务的
    3. 好的呀~

    2019-10-11
    4
  • Y
    老师你好
    业务中有个模块写极多读少,这种情况下是不是直接把这个数据拆分出来用单独nosql存储比较好?还是先写到nosql,再慢写到mysql好?
    如果慢写到mysql一是可能会出现数据不一致问题,二是写请求会积累很多,内存型nosql支撑不住,可能要用leveldb之类的,磁盘多了一份数据,等要迁移的时候又增加了运维管理成本

    作者回复: 如果是长期都是写多读少,那么可以考虑nosql
    如果是瞬时峰值的话,还是用消息队列削峰填谷

    2019-10-30
    2
  • 旅途
    学到了很多 第一次知道nosql快是因为索引,顺序io,赞赞赞
    2019-10-11
    2
  • yaomon
    目前的项目就是 MySql 配合 Elasticsearch 使用。Elasticsearch主要是做搜索用,写还是 MySql,同时发Kafka消息,消费端写ES。ES存在丢数据的问题,所以会定时全量/增量从 MySql 中捞数据,覆写 ES,保证数据的一直性。

    作者回复: 是的 应该是这样

    2019-10-11
    2
    2
  • gogo
    老师您好,你文中微博关系的例子中提到传统关系型数据库扩展性的短板,又说明了nosql有很好的性能和扩展性,请问拿微博关系的例子来说,是可以单独用nosql存储呢,还是既要存在nosql中又要保存在msylq中呢?

    作者回复: 大部分放在mysql,像是粉丝数据是在nosql

    2019-10-11
    2
  • 饭团
    老师,再问个问题!如果一类数据需要在nosql和关系形数据库都存储,需要存2次吗?现实开发中这样的情况多吗?能举个例子吗?

    作者回复: 是的呀 比如你的业务数据放在mysql,索引数据放在es

    2019-10-11
    1
    2
  • 饭团
    老师,是不是这个意思:
    首先不管是sql数据库还是nosql数据库,提升写性能都是靠的将随机写转化为顺序写!在这方面mysql使用WAL机制已经做的很好了!但是关系形数据库主要是在扩展性方面有缺陷!相对于除了kv型的nosql数据库,其他类型的和mysql性能都差不多!
    感觉mysql主要是在扩展性上有所欠缺!

    作者回复: benchmark结果来看,nosql的写入性能要好一些

    2019-10-11
    1
    2
  • XD
    老师不提一下tidb?
    2019-11-03
    1
  • ChenLicong
    关于《使用 NoSQL 提升写入性能》的那段,我还是有点想法:
    即使是NoSQL的一些组件,假如是写磁盘的话,再怎么优化改进,也跟MySQL等传统的关系型数据库的写入性能差不多,都是同一个量级的。
    Redis、MemCache等NoSQL数据库之所以读写性能高,是因为直接读写的内存,跟关系型数据库读写磁盘(也会缓存部分数据在内存中),利用的物理资源的性能都完全不是一个数量级。跟具体操作的物理资源的特性关系比较大。

    作者回复: 在实际运用中,nosql数据库比如leveldb确实比mysql有后来更好的写入性能

    2019-10-16
    2
    1
  • longslee
    打卡。咱用到了ElasticSearch和Redis。 选用ES是用来存储海量的,从Kafka入过来的。 Redis用于一些逻辑的过滤或者按时间聚合。 踩过的坑呀,我不知道算不算坑,还是说我们运维能力不够,Redis分布式以后,某个Key在哪,要去好多地方查- -

    作者回复: 怎么会呢,分布式之后应该可以知道某个key在哪个分片上

    2019-10-14
    2
    1
  • Liush
    老师你好:
    其实我对什么时候使用SQL,NOSQL,或者是NEWSQL一直存在很多疑问,就比如微博来说,每天微博增加的博文数量应该是非常大的,如果这部分用关系型数据库来存储是不是分库会很快达到瓶颈?这样会造成重新迁移分布数据,如果手动去迁移分布这部分数据,由于存在大量的历史数据迁移时间是否又是一个问题呢?像微博博文这部分是存储在SQL中还是NOSQL中?如果用nosql的话后续只要简单的将节点加入集群即可,auto sharding的特性会方便很多。如果按照我的理解在电商领域中,订单是核心系统,而且和订单系统关联的商品等数据,这部分使用关系型数据库分库分表的方式去处理,因为这部分系统需要保证事务,但是像商品详情这部分并不需要强事务的数据是否可以存储在NOSQL中?谢谢

    作者回复: 微博的博文是放在MySQL里面的,其实博文的数量没有关系那么夸张,而且热点明显,用户很少会翻之前的微博。
    订单的数据可能和博文的数据相当,我觉得放在mysql中应该就够了

    2019-10-14
    1
  • 大鸡腿🍗
    有点异议:原文说主键可能会随机IO,但是我觉得既然聚集索引物理,逻辑都有序,应该是顺序IO才对呀,老师
    2019-12-02
  • 布小丫学编程
    工作中使用过的Nosql数据库:
    ES,主要用来解决首页查询,通过logstash同步各个表的数据到ES,然后根据关键字进行查询。还有关键字联想也做了。
    Redis主要用来做缓存的,提高查询效率的,还有秒杀也会用到缓存先减库存。
    MongoDB主要用来存储非关系型数据,比如节点下再有节点。还有使用它来计算坐标点的距离。
    2019-11-19
  • 海罗沃德
    使用MongoDB作为一个中间层,把前端需要的跟展示页面相关的数据都按照JSON格式保存起来,后端通过消息队列的形式从实际业务数据库中读取数据维护MongoDB中的数据,前端写入数据时候也是直接更新MongoDB的数据,然后给消息队列发消息,让后端异步的去更新数据库,同时MongoDB中通过定时任务保证只存储热数据,超过10页以上的数据移动到AWS S3这样的文件存储系统中作为冷数据保存

    在非支付的业务场景下,这样避免前端直接查询和写入数据库,是否是一个可取的方案,老师对这样的方案有什么建议么?

    作者回复: 其实这就是把MongoDB作为“缓存”了,是可行的
    不过从描述来看,前端写入数据会更新MongoDB,再异步更新数据库;然后还会有一个消息队列会从业务数据库读取数据更新MongoDB,这两个是不是有重复?

    2019-11-04
  • XD
    对于mysql,插入时使用自增主键+WAL,更新时配合changebuffer似乎可以解决随机io带来的性能问题?

    作者回复: 可以缓解

    2019-11-03
  • 无形
    之前单表热点数据接近亿级,查询时间达到了8秒左右,后来进行了分表,按照ID取模分了一百张表,历史数据取模插入到分表中,新建了一张表用来保存全局唯一ID,每次新建热点都会更新全局唯一ID,保证分表之后ID唯一性,查询使用es,GitHub上找了一个开源的MySQL数据同步到es的工具,模拟的从库,保证了数据同步的实时性,热点数据查询性能降低到了1秒内。性能得到很大提升
    2019-11-01
收起评论
38
返回
顶部