关于申请开通网站建设的请示crm系统什么意思

当前位置： 首页 > news >正文

关于申请开通网站建设的请示,crm系统什么意思,网站360优化,开发者选项在哪里打开vivo上篇文章中#xff0c;我给你留了一个思考题#xff1a;在电商的交易类系统中#xff0c;如何正确地使用 Redis 这样的缓存系统呢#xff1f;需要考虑哪些问题#xff1f; 这篇文章#xff0c;我们来聊聊。 引言 我们知道#xff0c;大部分面向公众用户的互联网系统我给你留了一个思考题在电商的交易类系统中如何正确地使用 Redis 这样的缓存系统呢需要考虑哪些问题 这篇文章我们来聊聊。 引言 我们知道大部分面向公众用户的互联网系统它的并发请求数量是和在线用户数量正相关的而 MySQL 能承担的并发读写的量是有上限的当系统的在线用户超过几万到几十万这个量级的时候单台 MySQL 就很难应付了。 绝大多数互联网系统都使用 MySQL 加上 Redis 这对儿经典的组合来解决这个问题。Redis 作为 MySQL 的前置缓存可以替 MySQL 挡住绝大部分查询请求很大程度上缓解了 MySQL 并发请求的压力。 Redis 之所以能这么流行非常重要的一个原因是它的 API 非常简单几乎没有太多的学习成本。但是要想在生产系统中用好 Redis 和 MySQL 这对儿经典组合并不是一件很简单的事儿。 这篇文章我们就来说一下在电商的交易类系统中如何正确地使用 Redis 这样的缓存系统以及如何正确应对使用缓存过程中遇到的一些常见的问题。 更新缓存的最佳方式 要正确地使用好任何一个数据库你都需要先了解它的能力和弱点扬长避短。 Redis 是一个使用内存保存数据的高性能 KV 数据库它的高性能主要来自于 简单的数据结构使用内存存储数据 像数据库是分成了执行器和存储引擎两部分而Redis 的执行器这一层非常的薄所以 Redis 只能支持有限的几个 API几乎没有聚合查询的能力也不支持 SQL。它的存储引擎也非常简单直接在内存中用最简单的数据结构来保存数据你从它的 API 中的数据类型基本就可以猜出存储引擎中数据结构。 比如Redis 的 LIST 在存储引擎的内存中的数据结构就是一个双向链表。内存是一种易失性存储所以使用内存保存数据的 Redis 不能保证数据可靠存储。从设计上来说Redis 牺牲了大部分功能牺牲了数据可靠性换取了高性能。但也正是这些特性使得 Redis 特别适合用来做 MySQL 的前置缓存。 虽然说Redis 支持将数据持久化到磁盘中并且还支持主从复制但你需要知道Redis 仍然是一个不可靠的存储它在设计上天然就不保证数据的可靠性所以一般我们都使用 Redis 做缓存很少使用它作为唯一的数据存储。 即使只是把 Redis 作为缓存来使用我们在设计 Redis 缓存的时候也必须要考虑 Redis 的这种“数据不可靠性”或者换句话说我们的程序在使用 Redis 的时候要能兼容 Redis 丢数据的情况做到即使 Redis 发生了丢数据的情况也不影响系统的数据准确性。 我们以电商的订单系统来作为例子说明一下如何正确地使用 Redis 做缓存。在缓存 MySQL 的一张表的时候通常直接选用主键来作为 Redis 中的 Key比如缓存订单表那就直接用订单表的主键订单号来作为 Redis 中的 key。 如果说Redis 的实例不是给订单表专用的还需要给订单的 Key 加一个统一的前缀比如“orders:888888”。Value 用来保存序列化后的整条订单记录你可以选择可读性比较好的 JSON 作为序列化方式也可以选择性能更好并且更节省内存的二进制序列化方式都是可以的。 然后我们来说缓存中的数据要怎么来更新的问题。我见过很多人都是这么用缓存的在查询订单数据的时候先去缓存中查询如果命中缓存那就直接返回订单数据。如果没有命中那就去数据库中查询得到查询结果之后把订单数据写入缓存然后返回。在更新订单数据的时候先去更新数据库中的订单表如果更新成功再去更新缓存中的数据。 这其实是一种经典的缓存更新策略: Read/Write Through。 这样使用缓存的方式有没有问题绝大多数情况下可能都没问题。但是在并发的情况下有一定的概率会出现“脏数据”问题缓存中的数据可能会被错误地更新成了旧数据。  比如对同一条订单记录同时产生了一个读请求和一个写请求这两个请求被分配到两个不同的线程并行执行读线程尝试读缓存没命中去数据库读到了订单数据这时候可能另外一个读线程抢先更新了缓存在处理写请求的线程中先后更新了数据和缓存然后拿着订单旧数据的第一个读线程又把缓存更新成了旧数据。 这是一种情况还有比如两个线程对同一个条订单数据并发写也有可能造成缓存中的“脏数据”具体流程类似于我们在之前“电商系统架构设计系列三订单系统问题有哪些”这篇文章中讲到的 ABA 问题。你不要觉得发生这种情况的概率比较小出现“脏数据”的概率是和系统的数据量以及并发数量正相关的当系统的数据量足够大并且并发足够多的情况下这种脏数据几乎是必然会出现的。 另外有一个模式叫Cache Aside这个模式可以很好地解决这个问题在大多数情况下是使用缓存的最佳方式。 Cache Aside 模式和上面的 Read/Write Through 模式非常像它们处理读请求的逻辑是完全一样的唯一的一个小差别就是Cache Aside 模式在更新数据的时候并不去尝试更新缓存而是去删除缓存。 订单服务收到更新数据请求之后先更新数据库如果更新成功了再尝试去删除缓存中订单如果缓存中存在这条订单就删除它如果不存在就什么都不做然后返回更新成功。这条更新后的订单数据将在下次被访问的时候加载到缓存中。使用 Cache Aside 模式来更新缓存可以非常有效地避免并发读写导致的脏数据问题。 注意缓存穿透引起雪崩 如果我们的缓存命中率比较低就会出现大量“缓存穿透”的情况。缓存穿透指的是在读数据的时候没有命中缓存请求“穿透”了缓存直接访问后端数据库的情况。 少量的缓存穿透是正常的我们需要预防的是短时间内大量的请求无法命中缓存请求穿透到数据库导致数据库繁忙请求超时。大量的请求超时还会引发更多的重试请求更多的重试请求让数据库更加繁忙这样恶性循环导致系统雪崩。 当系统初始化的时候比如说系统升级重启或者是缓存刚上线这个时候缓存是空的如果大量的请求直接打过来很容易引发大量缓存穿透导致雪崩。为了避免这种情况可以采用灰度发布的方式先接入少量请求再逐步增加系统的请求数量直到全部请求都切换完成。 如果系统不能采用灰度发布的方式那就需要在系统启动的时候对缓存进行预热。所谓的缓存预热就是在系统初始化阶段接收外部请求之前先把最经常访问的数据填充到缓存里面这样大量请求打过来的时候就不会出现大量的缓存穿透了。 还有一种常见的缓存穿透引起雪崩的情况是当发生缓存穿透时如果从数据库中读取数据的时间比较长也容易引起数据库雪崩。 比如说我们缓存的数据是一个复杂的数据库联查结果如果在数据库执行这个查询需要 10 秒钟那当缓存中这条数据过期之后最少 10 秒内缓存中都不会有数据。 如果这 10 秒内有大量的请求都需要读取这个缓存数据这些请求都会穿透缓存打到数据库上这样很容易导致数据库繁忙当请求量比较大的时候就会引起雪崩。 所以如果说构建缓存数据需要的查询时间太长或者并发量特别大的时候Cache Aside 或者是 Read/Write Through 这两种缓存模式都可能出现大量缓存穿透。 对于这种情况并没有一种方法能应对所有的场景你需要针对业务场景来选择合适解决方案。比如说可以牺牲缓存的时效性和利用率缓存所有的数据放弃 Read Through 策略所有的请求只读缓存不读数据库用后台线程来定时更新缓存数据。 比如可以通过锁来解决“Cache aside和read/write through”而带来的数据不一致问题解决方案可以如下 a写线程b读线程 b线程读缓存-未命中-上写锁从db读数据到缓存-释放锁 a线程上写锁-写db-删除缓存/改缓存-释放锁 这样来保证ab线程并发读写缓存带来的脏数据问题 总结 使用 Redis 作为 MySQL 的前置缓存可以非常有效地提升系统的并发上限降低请求响应时延。绝大多数情况下使用 Cache Aside 模式来更新缓存都是最佳的选择相比 Read/Write Through 模式更简单还能大幅降低脏数据的可能性。 使用 Redis 的时候还需要特别注意大量缓存穿透引起雪崩的问题在系统初始化阶段需要使用灰度发布或者其他方式来对缓存进行预热。如果说构建缓存数据需要的查询时间过长或者并发量特别大这两种情况下使用 Cache Aside 模式更新缓存会出现大量缓存穿透有可能会引发雪崩。 顺便说一句文章中说到的这些缓存策略都是非常经典的理论早在互联网大规模应用之前这些缓存策略就已经非常成熟了在操作系统中CPU Cache 的缓存、磁盘文件的内存缓存它们也都应用了我们今天说到的这些策略。 所以无论技术发展的多快计算机的很多基础的理论的知识都是相通的你绞尽脑汁想出的解决工程问题的方法很可能早都写在几十年前出版的书里。学习算法、数据结构、设计模式等等这些基础的知识真的并不只是为了应付面试。 感谢阅读如果你觉得这篇文章对你有一些启发也欢迎把它分享给你的朋友。 上一篇文章 电商系统架构设计系列十怎么能避免写出慢SQL 推荐阅读 【总结】深入剖析 Redis 性能问题及优化方案有哪些【总结】互联网技术架构中常用的分库分表方案汇总技术破局业绩狂飙十倍亿级电商平台重构大揭秘当我们聊高并发时到底是在聊什么如何真正地掌握高并发设计能力微服务架构实战 - 我的经验分享总结2019系统架构师架构演进过程-从信息流架构到电商中台架构​​​​​​ 系列分享

Elasticsearch教程微服务架构实战架构思维成长系列电商系统架构设计系列 ——————————————————

我的CSDN主页 关于我个人域名更多我的信息 我的开源项目集Github 期望和大家 一起学习一起成长共勉O(∩_∩)O谢谢 如果你有任何建议或想学习的知识可与我一起讨论交流 欢迎交流问题可加个人QQ 469580884 或者加我的群号 751925591一起探讨交流问题 不讲虚的只做实干家 Talk is cheapshow me the code