竹磬网-邵珠庆の日记 生命只有一次,你可以用它来做些更多伟大的事情–Make the world a little better and easier


73月/170

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

发布在 邵珠庆

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

本次分享大纲

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

一、消息队列概述

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

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

二、消息队列应用场景

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

2.1异步处理

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

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

 

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

 

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

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

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

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

 

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

2.2应用解耦

场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。如下图: 

传统模式的缺点:

1)  假如库存系统无法访问,则订单减库存将失败,从而导致订单失败;

2)  订单系统与库存系统耦合;

如何解决以上问题呢?引入应用消息队列后的方案,如下图:

 

  • 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。
  • 库存系统:订阅下单的消息,采用拉/推的方式,获取下单信息,库存系统根据下单信息,进行库存操作。
  • 假如:在下单时库存系统不能正常使用。也不影响正常下单,因为下单后,订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

2.3流量削锋

流量削锋也是消息队列中的常用场景,一般在秒杀或团抢活动中使用广泛。

应用场景:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要在应用前端加入消息队列。

  1. 可以控制活动的人数;
  2. 可以缓解短时间内高流量压垮应用;

 

  1. 用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面;
  2. 秒杀业务根据消息队列中的请求信息,再做后续处理。

2.4日志处理

日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。架构简化如下:

 

  • 日志采集客户端,负责日志数据采集,定时写受写入Kafka队列;
  • Kafka消息队列,负责日志数据的接收,存储和转发;
  • 日志处理应用:订阅并消费kafka队列中的日志数据;

以下是新浪kafka日志处理应用案例:

转自(http://cloud.51cto.com/art/201507/484338.htm)

 

(1)Kafka:接收用户日志的消息队列。

(2)Logstash:做日志解析,统一成JSON输出给Elasticsearch。

(3)Elasticsearch:实时日志分析服务的核心技术,一个schemaless,实时的数据存储服务,通过index组织数据,兼具强大的搜索和统计功能。

(4)Kibana:基于Elasticsearch的数据可视化组件,超强的数据可视化能力是众多公司选择ELK stack的重要原因。

2.5消息通讯

消息通讯是指,消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等。

点对点通讯:

 

客户端A和客户端B使用同一队列,进行消息通讯。

聊天室通讯:

 

客户端A,客户端B,客户端N订阅同一主题,进行消息发布和接收。实现类似聊天室效果。

以上实际是消息队列的两种消息模式,点对点或发布订阅模式。模型为示意图,供参考。

三、消息中间件示例

3.1电商系统

 

消息队列采用高可用,可持久化的消息中间件。比如Active MQ,Rabbit MQ,Rocket Mq。

(1)应用将主干逻辑处理完成后,写入消息队列。消息发送是否成功可以开启消息的确认模式。(消息队列返回消息接收成功状态后,应用再返回,这样保障消息的完整性)

(2)扩展流程(发短信,配送处理)订阅队列消息。采用推或拉的方式获取消息并处理。

(3)消息将应用解耦的同时,带来了数据一致性问题,可以采用最终一致性方式解决。比如主数据写入数据库,扩展应用根据消息队列,并结合数据库方式实现基于消息队列的后续处理。

3.2日志收集系统

 

分为Zookeeper注册中心,日志收集客户端,Kafka集群和Storm集群(OtherApp)四部分组成。

  • Zookeeper注册中心,提出负载均衡和地址查找服务;
  • 日志收集客户端,用于采集应用系统的日志,并将数据推送到kafka队列;
  • Kafka集群:接收,路由,存储,转发等消息处理;

Storm集群:与OtherApp处于同一级别,采用拉的方式消费队列中的数据;

286月/160

阿里系列:OSS存储作为本地数据盘挂载

发布在 邵珠庆

https://github.com/aliyun/ossfs#ossfs

简介

ossfs 能让您在Linux/Mac OS X 系统中把Aliyun OSS bucket 挂载到本地文件 系统中,您能够便捷的通过本地文件系统操作OSS 上的对象,实现数据的共享。

功能

ossfs 基于s3fs 构建,具有s3fs 的全部功能。主要功能包括:

- 支持POSIX 文件系统的大部分功能,包括文件读写,目录,链接操作,权限, uid/gid,以及扩展属性(extended attributes)
- 通过OSS 的multipart 功能上传大文件。
- MD5 校验保证数据完整性。

安装

预编译的安装包

我们为常见的linux发行版制作了安装包:

- Ubuntu-14.04
- CentOS-7.0/6.5/5.11

请从版本发布页面选择对应的安装包下载安装,建议选择最新版本。

- 对于Ubuntu,安装命令为:

sudo apt-get update
sudo apt-get install gdebi-core
sudo gdebi your_ossfs_package

- 对于CentOS6.5及以上,安装命令为:(安装包下载https://github.com/aliyun/ossfs/releases)

sudo yum localinstall your_ossfs_package

- 对于CentOS5,安装命令为:

sudo yum localinstall your_ossfs_package --nogpgcheck

源码安装

如果没有找到对应的安装包,您也可以自行编译安装。编译前请先安装下列依赖库:

Ubuntu 14.04:

sudo apt-get install automake autotools-dev g++ git libcurl4-gnutls-dev \
libfuse-dev libssl-dev libxml2-dev make pkg-config

CentOS 7.0:

sudo yum install automake gcc-c++ git libcurl-devel libxml2-devel \
fuse-devel make openssl-devel

然后您可以在github上下载源码并编译安装:

git clone https://github.com/aliyun/ossfs.git
cd ossfs
./autogen.sh
./configure
make
sudo make install

运行

设置bucket name, access key/id信息,将其存放在/etc/passwd-ossfs 文件中, 注意这个文件的权限必须正确设置,建议设为640。

echo my-bucket:my-access-key-id:my-access-key-secret > /etc/passwd-ossfs
chmod 640 /etc/passwd-ossfs

将oss bucket mount到指定目录

ossfs my-bucket my-mount-point -ourl=my-oss-endpoint

示例

将my-bucket这个bucket挂载到/tmp/ossfs目录下,AccessKeyId是faint, AccessKeySecret是123,oss endpoint是http://oss-cn-hangzhou.aliyuncs.com

# 安装
sudo yum localinstall ossfs_1.79.9_centos6.5_x86_64.rpm
echo wzj:nnnnnnnnnnnn:xxxxxxxxxxxxxxxxxx > /etc/passwd-ossfs
chmod 640 /etc/passwd-ossfs
mkdir /home/oss

# 启动
ossfs weizaojiao /home/oss -ourl=http://oss-cn-qingdao-internal.aliyuncs.com
/etc/init.d/目录下建立文件ossfs,放入ossfs weizaojiao /home/oss -ourl=http://oss-cn-qingdao-internal.aliyuncs.com
chmod a+x /etc/init.d/ossfs
chkconfig ossfs on

# 卸载
umount /home/oss
# 跳过扫描
我们常用到的3个查找命令分别是whereis,find,locate。
这其中,find命令是最老实巴焦的一个,直接在指定的目录下进行搜索,如果实在不知道在哪,我们就用 find / -name xxx
而另外的两个命令在搜索之前,都要读取 /etc/updatedb.conf (文件检索数据库配置信息)这个文件。
一般,我们为了加速检索,我们经常 updatedb 一下,这时候,它俩就过滤掉一些没用的东西,进行检索。
updatedb.conf下的几个变量分别是:
PRUNE_BIND_MOUNTS="yes" //是否限制搜索
#PRUNENAMES=".git .bzr .hg .svn" //跳过的文件类型,不同后缀之间用空格隔开。这个功能默认是关闭的(用#注释掉了),如果需要打开需将#去掉
PRUNEPATHS="/tmp /var/spool /media /home/.ecryptfs /home/oss" //要跳过的路径,/media 表示其他硬盘
PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.ossfs" //要搜索的文件系统

常用设置

- 使用ossfs --version来查看当前版本,使用ossfs -h来查看可用的参数

- 如果使用ossfs的机器是阿里云ECS,可以使用内网域名来避免流量收费和 提高速度:

- ossfs my-bucket /tmp/ossfs -ourl=http://oss-cn-hangzhou-internal.aliyuncs.com

- 在linux系统中,updatedb会定期地扫描文件系统,如果不想 ossfs的挂载目录被扫描,可参考FAQ设置跳过挂载目录

- 如果你没有使用eCryptFs等需要XATTR的文件系统,可 以通过添加-o noxattr参数来提升性能

- ossfs允许用户指定多组bucket/access_key_id/access_key_secret信息。当 有多组信息,写入passwd-ossfs的信息格式为:
bucket1:access_key_id1:access_key_secret1
bucket2:access_key_id2:access_key_secret2

- 生产环境中推荐使用supervisor来启动并监控ossfs进程,使 用方法见FAQ

高级设置

- 可以添加-f -d参数来让ossfs运行在前台并输出debug日志
- 可以使用-o kernel_cache参数让ossfs能够利用文件系统的page cache,如 果你有多台机器挂载到同一个bucket,并且要求强一致性,请不要使用此 选项

遇到错误

遇到错误不要慌:) 按如下步骤进行排查:

- 如果有打印错误信息,尝试阅读并理解它

- 查看/var/log/syslog或者/var/log/messages中有无相关信息

- grep 's3fs' /var/log/syslog
grep 'ossfs' /var/log/syslog

- 重新挂载ossfs,打开debug log:
ossfs ... -o dbglevel=debug -f -d > /tmp/fs.log 2>&1

然后重复你出错的操作,出错后将/tmp/fs.log保留,自己查看或者发给我

局限性

ossfs提供的功能和性能和本地文件系统相比,具有一些局限性。具体包括:

- 随机或者追加写文件会导致整个文件的重写。
- 元数据操作,例如list directory,性能较差,因为需要远程访问oss服务器。
- 文件/文件夹的rename操作不是原子的。
- 多个客户端挂载同一个oss bucket时,依赖用户自行协调各个客户端的行为。例如避免多个客户端写同一个文件等等。
- 不支持hard link。
- 不适合用在高并发读/写的场景,这样会让系统的load升高