高并发数据采集的架构应用(Redis的应用)

问题的出发点:

      最近公司为了发展需要,要扩大对用户的信息采集,每个用户的采集量估计约3W。如果用户量增加的话,将会大量照成采集量成3W倍的增长,但是又要满足日常业务需要,特别是报表数据必要在规定的时间内完成。

技术障碍:

     1. 面对用户量的增长,记录数3W倍的增长,如何保证这些记录能够在比较快的时间内进入存储介质。

   2. 应对用户量的增长,如何在规定的时间内完成采集,增加硬件设备处理能力还是使用更多的服务器来处理请求。

3. 服务器的增长,是否能够支持现有的扩展能力。

架构实现:

使用到的技术项:

     1. 面向服务开发思维

2. 队列服务

3. 多任务并发执行

4. 分布式服务管理

5. Redis的应用

6. 数据分表(分区)的实现和应用

7. Redis异步延迟同步到数据库

架构图如下:

具体实现:

1. 队列服务可以采用HttpsQs

2. 多任务并发执行,PHP版可采用ParallelCurl,可控制并发数量

3. 可使用PHP Redis实现对Redis的操作

4. 数据表分表或者分区,可自行动手写个,原理很简单,需要指导的可以发私密信

总结:

整个方案不是很复杂,在处理大数据方向这块,基本的原理都是一样,把不可控的因素要把握住,所以在多任务并发这块一定要控制到合理的数量,另外Redis缓存也支持分布式集群,增加Redis服务器并不会影响上层代码的改变,相对来说扩容能力还是相对不错。

时间: 2024-08-29 18:37:31

高并发数据采集的架构应用(Redis的应用)的相关文章

亿级数据的高并发通用搜索引擎架构设计(转-张宴)

[文章作者:张宴 本文版本:v1.0 最后修改:2008.12.09 转载请注明原文链接:http://blog.zyan.cc/post/385/] 曾经在七月,写过一篇文章──<基于Sphinx+MySQL的千万级数据全文检索(搜索引擎)架构设计>, 前公司的分类信息搜索基于此架构,效果明显,甚至将很大一部分带Where条件的MySQL SQL查询,都改用了Sphinx+MySQL搜索.但是,这套架构仍存在局限:一是MySQL本身的并发能力有限,在200-300个并发连接下,查询 和更新就

高并发大型网站架构设计

一个大型的网站网站应该由如下6个子系统组成 负载均衡系统 反向代理系统 Web服务器系统 分布式存储系统 底层服务系统 数据库集群系统 为什么要做高并发系统设计? 事实上,针对于任何单一的网络服务器程序,其可承受的同时连接数目是有理论峰值的,通过C++中对TSocket的定义类型:word,我们可以判 定这个连接理论峰值是65535,也就是说,你的单个服务器程序,最多可以承受6万多的用户同时连接.但是,在实际应用中,能达到一万人的同时连接并能保 证正常的数据交换已经是很不容易了,通常这个值都在2

【转载】千万级规模高性能、高并发的网络架构经验分享

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重视它,战术上又要藐视它.先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右.对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 .为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据

【并发与负载】千万级规模高性能、高并发的网络架构经验分享

架构以及我理解中架构的本质 在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它.先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右.对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 .为什么我们又不能说轻视它?第一,

【总结】瞬时高并发(秒杀/活动)Redis方案(转)

转载地址:http://bradyzhu.iteye.com/blog/2270698 1,Redis 丰富的数据结构(Data Structures) 字符串(String) Redis字符串能包含任意类型的数据 一个字符串类型的值最多能存储512M字节的内容 利用INCR命令簇(INCR, DECR, INCRBY)来把字符串当作原子计数器使用 使用APPEND命令在字符串后添加内容 列表(List) Redis列表是简单的字符串列表,按照插入顺序排序 你可以添加一个元素到列表的头部(左边:

9种高性能可用高并发的技术架构

1.分层 分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统. 在网站的分层架构中,常见的为3层,即应用层.服务层.数据层.应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务,如数据库.缓存.文件.搜索引擎等. 分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层

高并发IM系统架构优化实践

互联网+时代,消息量级的大幅上升,消息形式的多元化,给即时通讯云服务平台带来了非常大的挑战.高并发的IM系统背后究竟有着什么样的架构和特性 本文要点: 网易云信整体架构解析 云信中的客户端连接和接入点管理 服务化和高可用 网易IM云分层架构图解析 底层客户端SDK,覆盖了安卓,iOS,windows PC桌面端,web网页端和嵌入式设备等多个平台.在SDK层使用的网络协议有4层的TCP协议和基于7层的Socket.IO协议,后者专门用于Web SDK中提供长连接能力:除了集成到应用App中的SD

一个老项目的高并发改造,遇到的redis连接不释放问题。

问题来由 一个老系统使用频率很低,但是一旦用,就是很多人一起用.每次这个时候,服务都会挂掉. 原因是使用mysql数据库做复杂计算.没有使用缓存. 着手解决 框架版本 struts 2.0 spring 3.2 集成redis <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmln

高并发大访问量架构设计演进之路 归纳总结

第01:大型架构的演进之路第02(上):分布式缓存第02(下):分布式缓存第03:分布式消息队列第04:分布式数据存储第05:分布式服务框架第06:高性能系统架构第07:高可用系统架构第08:系统的安全架构第09:架构实战案例分析第10:如何成为技术专家 系统的垂直伸缩,水平伸缩系统的性能瓶颈:分部式缓存:分布式数据存储,分布式服务架构: 强烈的好奇心,工程技术,产生价值赚钱(科学研究不同)扎实的软件技术基础:操作系统,数据结构,设计模式,编程语言,出色的编程能力:优秀的代码深刻领悟主流技术产品