Author: admin

浏览器缓存知识小结及应用

浏览器缓存,也就是客户端缓存,既是网页性能优化里面静态资源相关优化的一大利器,也是无数web开发人员在工作过程不可避免的一大问题,所以在产品开发的时候我们总是想办法避免缓存产生,而在产品发布之时又在想策略管理缓存提升网页的访问速度。了解浏览器的缓存命中原理,是开发web应用的基础,本文着眼于此,学习浏览器缓存的相关知识,总结缓存避免和缓存管理的方法,结合具体的场景说明缓存的相关问题。希望能对有需要的人有所帮助。…

大型网站架构系列:分布式消息队列

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统)。

本次分享大纲

  1. 消息队列概述
  2. 消息队列应用场景
  3. 消息中间件示例
  4. JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)
  5. 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)
  6. 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)
  7. 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)

一、消息队列概述

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。

二、消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景。

2.1异步处理

场景说明:用户注册后,需要发注册邮件和注册短信。传统的做法有两种1.串行的方式;2.并行方式。

(1)串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端。(架构KKQ:466097527,欢迎加入)

(2)并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间。

假设三个业务节点每个使用50毫秒钟,不考虑网络等其他开销,则串行方式的时间是150毫秒,并行的时间可能是100毫秒。

因为CPU在单位时间内处理的请求数是一定的,假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次(1000/150)。并行方式处理的请求量是10次(1000/100)。

 

小结:如以上案例描述,传统的方式系统的性能(并发量,吞吐量,响应时间)会有瓶颈。如何解决这个问题呢?

引入消息队列,将不是必须的业务逻辑,异步处理。改造后的架构如下:

按照以上约定,用户的响应时间相当于是注册信息写入数据库的时间,也就是50毫秒。注册邮件,发送短信写入消息队列后,直接返回,因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。因此架构改变后,系统的吞吐量提高到每秒20 QPS。比串行提高了3倍,比并行提高了两倍。

2.2应用解耦

场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。如下图:(架构KKQ:466097527,欢迎加入)

传统模式的缺点:

HTTP2学习(四)—HTTP2的新特性

HTTP2可以让我们的应用变得更快、更简单、更健壮,让我们在HTTP1.1时针对TCP协议特性而做的用来提高性能的HACK一笔勾销。

总览

为了提高应用的性能,降低延迟,我们能做的无外乎2点,要么传输的东西越小越好,要么距离能获得资源的地方越近越好。

这个就好比说是运动员赛跑,为了最先到达终点,在相同的速度下,当然是离终点越近,用时会越短;另一方面,在距离相等的情况下,当然是降低自上多余的重量,让速度越快越好,这也是为什么短跑运动员穿紧身运动服,鞋带都要藏起来的原因,为了最大限度的降低在空气中的阻力,提高速度。…

        

HTTP/2提升性能的7个建议

历史悠久的超文本传输协议,即HTTP标准,最近版本升级了。HTTP/2在2015年5月被批准,目前已经在很多Web浏览器和服务器中得到实现(包括NGINX Plus和开源NGINX)。大约有三分之二的浏览器已经支持HTTP/2,而且这个比例每月都在增加。

HTTP/2构建在Google SPDY协议基础之上,Chrome将在2016年年初停止对后者的支持。NGINX是最早支持SPDY的,如今同样率先支持了HTTP/2。为此,我们还发布了详尽的白皮书(PDF),介绍了HTTP/2以及它如何基于SPDY构建,并展示了如何实现这个新协议。…

        

REST真的完全适合微服务架构吗?

【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。

在我接触微服务的这段时间,大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此,你可能理所当然地认为REST就是微服务的一种标准,并且是设计与实现微服务系统一种方式。然而,并非如此。…

        

进程间通信之FIFO

FIFO有时被称为命名管道。管道只能由相关进程使用,这些相关进程的共同祖先进程创建了管道。但是,通过FIFO,不相关的进程也能交换数据

FIFO是一种文件类型(参考http://www.cnblogs.com/nufangrensheng/p/3501533.html)。stat结构(http://www.cnblogs.com/nufangrensheng/p/3501385.html)成员st_mode的编码指明文件是否是FIFO类型。可以用S_ISFIFO()宏对此进行测试。…

线程安全与可重入函数

线程安全:一个函数被称为线程安全的(thread-safe),当且仅当被多个并发进程反复调用时,它会一直产生正确的结果。如果一个函数不是线程安全的,我们就说它是线程不安全的(thread-unsafe)。我们定义四类(有相交的)线程不安全函数。

第1类:不保护共享变量的函数…

被误解的TCP

文:林沛满
人一旦形成某种思维定势,就很难再改变了。知道我收到最多的读者来信是问什么吗?“林工,有些TCP包发出去之后没有看到对应的Ack,算不算丢包啊?”这个问题让我很是好奇,明明RFC上没有这样的规定,为什么总有读者觉得每一个数据包都应该有对应的Ack呢?后来才注意到,很多提问者是做网站开发出身的,已经习惯了每个HTTP请求发出去,就一定会收到一个HTTP响应(见图1),因此就把这个模式套到了TCP上。其实不止HTTP,绝大多数应用层协议都采用这种一问一答的工作方式。…