「全栈之路」Web前端开发的后端指南

  • 用户通过表单上传的各类文件。
  • 云服务供应商不是将这些存储在数据库中,而是提供专用服务来存储这些服务,例如 AWSSimpleStorageService(S3), Azure, GoogleCloudStorage和阿里云 OSS等。

    这样做的好处是云供应商可以安全地存储文件,并可以为其制作冗余副本,以最大限度地降低数据丢失的风险。

    6.1 关于 Blob 存储:

    Blob 存储用于:

    • 直接向浏览器提供图像或文档。
    • 存储文件以供分布式访问。
    • 对视频和音频进行流式处理。
    • 向日志文件进行写入。
    • 存储用于备份和还原、灾难恢复及存档的数据。
    • 存储数据以供本地或 Azure 托管服务执行分析

    7、内容分发网络(CDN)

    Blob /文件存储服务允许客户端通过 HTTP端点访问文件。例如,您的Web应用程序的HTML标记可以简单地链接到AWS S3中存储的图像和CSS文件的URL。

    传统网络访问

    「全栈之路」Web前端开发的后端指南

    但是,假设我的用户位于中国,我的S3存储位于美国西部 - 数据传输距离数千英里,因此我的用户会看到延迟。

    CDN是什么?使用CDN有什么优势?

    • CDN是云供应商提供的服务,它们在全球范围内分布有“边缘服务器”。
    • 这些边缘服务器从“原点”(例如,blob /文件存储位置)获取文件的副本。你的前端Web应用程序将指向 其CDN URL,而不是指向静态资产的Blob存储URL。
    • 现在,客户端和“边缘”之间的距离远不是几千英里的往返,而是更少,因此文件的获取速度更快。

    使用了CDN的网站访问:

    「全栈之路」Web前端开发的后端指南

    7.1 CDN工作流

    「全栈之路」Web前端开发的后端指南

    通过权威DNS服务器来实现最优节点的选择,通过缓存来减少源站的压力。

    8、缓存服务:CachingService

    虽然 CDN是静态文件的一种缓存形式,但 Web应用程序可能需要临时缓存动态数据。

    例如,假设存在一个数据库查询,该查询对昨天的数据执行计算,其结果每天经常被成千上万的用户访问。每次用户请求此数据时联系数据库就没有任何意义。

    对此的解决方案是使用高速缓存服务在第一个用户请求之后将结果存储一段时间。通过缓存将更快地提供对该数据的后续请求。

    缓存服务本质上是一种特殊类型的数据库。 缓存采用键值存储的形式,其中键是应用程序代码用于查询数据的字符串(例如DailySiteStats_2018-10-17),值是缓存的实际数据。缓存的数据通常完全保存在内存中,这使得从缓存中检索数据的速度非常快。

    常见的缓存服务是 Redis和 Memcached。AWS通过其 Elasticache服务提供这两者的托管版本。

    8.1 Redis和 Memcached对比

    Redis和 Memcached是都是主流的开源内存数据存储。虽然它们既易于使用又提供高性能,但在选择引擎时需要考虑重要的差异。Memcached是为简单而设计的,而 Redis提供了丰富的功能,使其能够广泛用于各种用例。


    MemcachedRedis亚毫秒级延迟是是开发人员易用性是是数据分区是是多语言支持是是高级数据结构-是多线程架构是-快照-是复制-是发布/订阅-是Lua脚本-是地理空间支持-是

    亚毫秒级延迟:

    Redis和 Memcached都支持亚毫秒的响应时间。通过将数据存储在内存中,它们可以比基于磁盘的数据库更快地读取数据。

    开发人员易用性:

    Redis和 Memcached在语法上都很容易使用,并且需要最少量的代码才能集成到您的应用程序中。

    数据分区:

    Redis和Memcached`都允许您在多个节点之间分发数据。这允许您在需求增长时向外扩展以更好地处理更多数据。

    支持广泛的编程语言:

    Redis和 Memcached都有许多面向开发人员的开源客户端。支持的语言包括 Java,Python,PHP,C,C++,C#,JavaScript,Node.js,Ruby,Go等等。

    高级数据结构:

    除了字符串, Redis还支持列表,集合,有序集,哈希,位数组等。应用程序可以使用这些更高级的数据结构来支持各种用例。例如,你可以使用Redis排序集轻松实现游戏排行榜,该排行榜保持按其排名排序的玩家列表。

    多线程架构

    由于 Memcached是多线程的,因此它可以使用多个处理核心。这意味着您可以通过扩展计算容量来处理更多操作。

    快照:

    使用 Redis,您可以使用即时快照将数据保存在磁盘上,该快照可用于存档或恢复。

    复制:

    Redis允许您创建 Redis主数据库的多个副本。这允许您扩展数据库读取并具有高可用性集群。

    发布/订阅:

    Redis支持使用模式匹配的 Pub/Sub消息传递,您可以将其用于高性能聊天室,实时评论流,社交媒体源和服务器互通。

    Lua脚本:

    Redis允许您执行事务性 Lua脚本。脚本可以帮助您提高性能并简化应用程序。

    地理空间支持:

    Redis具有专门用于大规模处理实时地理空间数据的命令。您可以执行诸如查找两个元素(例如人或地点)之间的距离以及查找点的给定距离内的所有元素之类的操作。

    9、消息队列:Message queue

    「全栈之路」Web前端开发的后端指南

    适用于批处理任务和分离应用程序的异步消息收发

    有时,你程序需要执行的任务与响应用户请求没有直接关系。

    例如,假设用户上传了需要编码和水印的视频。但这是一项长期运行的任务,因此让用户在完成时等待是没有意义的。更好的方法是异步执行此操作。您的网络应用程序代码会在队列中创建一条作业消息,并通知您的用户,当水印视频准备就绪时,他们将收到一封电子邮件(消息)。

    然后,你将拥有一个可以执行以下操作的工作任务流:

    1. 从队列中读取消息。
    2. 开始处理视频。
    3. 完成后,保存视频的编码副本。
    4. 向用户发送通知电子邮件(消息)。
    5. 从队列中删除消息。

    这里有2个架构组件:

    您可以通过以下几种方式实现 worker任务:

    • 调度 CRON作业以触发应用程序服务器上安装的指定代码,以便按特定计划从队列中读取。
    • 将消息添加到队列时,使用 FaaS平台调用工作器代码。

    9.1 Message queue 简介

    消息队列是一种异步的服务间通信方式,适用于无服务器和微服务架构。消息在被处理和删除之前一直存储在队列上。每条消息仅可被一位用户处理一次。消息队列可被用于分离重量级处理、缓冲或批处理工作以及缓解高峰期工作负载。

    现在常用的MQ组件有 activeMQ、 rabbitMQ、 rocketMQ、 zeroMQ 还有近年来火热的 kafka,从某些场景来说也是MQ,当然kafka的功能更加强大,虽然不同的MQ都有自己的特点和优势,但是,不管是哪种MQ,都有MQ本身自带的一些特点。

    9.2 MQ主要特性

    特性说明推送或拉取传送拉取是指不断查询队列以获取新消息。推送是指系统在有可用消息时通知用户 (也称为发布/订阅消息收发)。您还可以使用长轮询让拉取等待指定的时间,以便新消息在完成之前到达。定时或延迟传送支持为消息设置特定的传送时间。如果需要为所有消息设置相同延迟,可以设置一个延迟队列。至少一次传送消息队列可以存储多个消息副本以实现冗余和高可用性,并在发生通信故障或错误的情况下重新发送消息,以确保它们至少经过一次传送。确切一次传送在不容许重复的情况下,FIFO (先进先出) 消息队列会通过自动筛选重复来确保每个消息均精确地传输了一次 (且只有一次)。FIFO (先进先出) 队列在这些队列中,首先接受处理的是最早的 (或第一个) 条目,有时称为“队首”。消息优先级通常情况下,您可以为消息分配优先级,以确定要在队列中添加该消息的位置,从而确保优先级较高的消息位于队列前端并得到优先处理。

    9.3 MQ应用示例

    来源:MQ(消息队列)常见的应用场景解析

    我们的实际场景大概是一个基于微服务架构的电商系统,分为用户微服务、商品微服务、订单微服务、促销微服务等。

    基于微服务模式开发的系统,MQ的使用场景更多。这里我们就列举一下常见的应用示例。

    1、注册后的初始化

    注册后我们可能需要做很多初始化的操作,如:

    • 调用邮件服务器发送邮件、调用促销服务赠送优惠劵、下发用户数据到客户关系系统等。
    • 那么这时候我们将这些操作去监听MQ,当用户注册成功过后,通过MQ通知其他业务进行操作。确保注册用户的性能。

    2、后台发布商品

    后台发布商品的时候:

    • 商品数据需要从数据库中转换成搜索引擎数据(基于 elasticsearch)
    • 那么我们应该将商品写入数据库后,再写入到 MQ,然后通过监听 MQ来生成 elasticsearch对应的数据。

    3、支付超时取消

    用户下单后,24小时未支付,需要取消订单。

    • 以前我们可能是定时任务循环查询,然后取消订单。
    • 实际上,我更推荐类似延迟MQ的方式,避免了很多无效的数据库查询,将一个MQ设置为24小时后才让消费者消费掉,这样很大程度上能减轻服务器压力。

    4、支付完成后通知

    • 支付完成后,需要及时的通知子系统(进销存系统发货,用户服务积分,发送短信)进行下一步操作。
    • 但是,支付回调我们都是需要保证高性能的,所以,应该直接修改数据库状态,存入MQ,让MQ通知子系统做其他非实时的业务操作。这样能保证核心业务的高效及时。


    分享到:


    相關文章: