昂捷论坛≡零售最前线≡□-技术研讨会 → 大规模并发性能问题探讨


  共有21290人关注过本帖树形打印

主题:大规模并发性能问题探讨

帅哥哟,离线,有人找我吗?
飞絮
  1楼 个性首页 | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信
等级:中校 帖子:594 积分:6649 威望:0 精华:56 注册:2005/10/21 18:45:15
大规模并发性能问题探讨  发帖心情 Post By:2013/3/21 0:21:25



何谓大规模并发,不同层面有不同的理解

企业应用(Intranet):千级强并发,万级弱并发(在线用户),十万级用户

 

  •     大型企业ERP、供应链,大型企业HR、办公OA

互联网应用(Internet):百万级强并发,千万级弱并发(在线用户),亿级用户/

  • 门户网站(新浪、腾讯)
  • 平台级电子商务(阿里巴巴、淘宝网、拍拍网)
  • 搜索引擎(百度)

电子商务企业应用(Intranet + Internet):十万级强并发,百万级弱并发(在线用户),千万级用户

  • B2C电子商务(京东、凡客、一号店)
  • 垂直型电子商务(金银岛、携程)


不同系统间的并发特点
企业系统
大量事务性、实时性访问

  • 大量的事务、锁检测导致数据库访问瓶颈
  • 需要数据操作的实时更新
大量有状态性访问
  • 数据访问具有较强的操作上下文
  • 数据一致性、准确性的高敏感
  • 数据每一次事务性更新都必须得到充分展现,并且确保数据访问的一致性
清晰的业务逻辑进行并发划分
  • 一般来说,企业系统都可以进行明确的业务区分,从而决定系统特点

互联网系统
海量非事务性访问
  • 极其巨大的数据量及数据访问导致IO操作成为瓶颈
模糊的并发区分
  • 并发访问的用户中很难通过内容进行有效分发
  • 并发访问一般具有地域性
数据访问效率的高敏感
  • 用户对系统的响应时间非常敏感,需要在几秒内得到信息反馈
  • 用户更加在意数据的匹配性

电子商务系统
数据实时性的高敏感
价格、信息同步的一致性等
受制于企业级系统的约束
  • 如支付,受事务性影响
海量非事务性访问+一定规模事务性访问
信息访问具有互联网系统特点、信息操作具有企业系统特点
  • 如数据的搜索查询、展现具有互联网系统特点
  • 如数据的操作(支付、结算)具有企业系统事务性特点

什么是性能问题
  • 在可识别的压力下,系统无法提供服务 (最差的性能问题)
  • 在可识别的压力下,系统无法按服务质量标准提供服务 (满足性能标准,但是健壮性不足)
  • 在可识别的压力下,系统无法持续按服务质量标准提供服务 (系统的可靠性和健壮性)
  • 在超过识别的压力下,系统无法尽快恢复
  • 能否有故障转移、故障恢复、冗余热备等机制
  • 在超过识别的压力下,系统无法柔性伸缩 (系统的可伸缩性)
什么不是性能问题
  • 超过可识别的压力情况下,系统暂时无法有效提供服务

性能测量
服务质量
  • 网络响应:网络响应时间、网络吞吐量、网络带宽及带宽利用率
  • 服务响应时间:包括平均、峰值、标准区间值
  • 服务处理质量:事务成功率、单位时间响应事务次数
服务端设备状态
  • CPU:CPU使用率
  • 内存:使用内存大小
  • VM:GC次数(Full GC次数)、堆内存、线程数、锁和阻塞情况
  • 磁盘IO:磁盘访问效率、磁盘空间、磁盘IO吞吐量
系统可靠性、健壮性
  • 单节点处理的访问量
  • 故障恢复时间
  • 节点复制和节点扩展的难易

 

系统可能的性能瓶颈
网络

  • 网络带宽的总体限制
  • 网络连接数的限制(如TCP/IP, 数据库连接等)
服务器
  • 每个响应占用相应的资源,导致内存成为瓶颈
  • 比如JVM为每个线程分配栈空间,过多栈空间导致内存消耗
  • 比如每个HTTP连接在Session存储内容,导致OOME
  • 同时响应一定量的并发操作,导致CPU占用过高
磁盘IO
  • 频繁访问数据库,导致数据交换IO操作频繁
  • 频繁访问IO文件,导致磁盘IO成为瓶颈

企业级系统架构及技术特点
架构设计
基于SOA和MDA的架构
  • 以服务为核心单元的 设计思想,以传统WS作为服务发布
  • 以模块化为系统构建方式,重视应用子系统和子模块的独立性和可重用性
中央集中式部署架构
  • 专业小型服务器
  • 一般不会超过5台部署服务器,不会多于10个应用节点
  • 热备和故障恢复机制、灾备系统
关注流程
  • 工作流技术,尤其是分布式节点间流程整合
  • 企业系统间的无缝转移
门户
  • 跨系统,跨节点间的单点登录

技术运用
以商业性产品为主
  • 追求单节点稳定性
  • 较少需要7*24小时支持
  • 以商业性关系数据库为主要存储
比较严格的事务性访问
  • 完全基于数据库事务
  • 分布式事务(JTA)
较为复杂并且功能丰富的用户界面
  • 用户具有相对统一的客户端(比如使用IE浏览器)
  • 用户可以接受适当的响应和延迟

 

互联网系统架构及技术特点
架构设计
以界面展现和用户体验为主要设计

  • 大量运用Ajax实现局部提交和局部刷新
以轻量级、伸缩性为架构主要考虑
  • 除某些平台级应用外,极少使用服务扩展
  • 使用REST风格的WebService或者纯粹的处理Json的Web响应
  • 数以百台甚至上万台PC服务器,多个数据中心,站点镜像
  • 分布式独立域以及部署域之间定时通信
高性能缓存机制
  • 双向页面缓存
  • 内容静态化技术
  • 数据缓存
非事务、非关系型数据库
  • 全面NoSQL数据库

技术运用
大量使用开源技术产品
  • LAMP: Linux + Apache + MySQL + PHP
  • Tomcat, Lucene, Memcache
简单界面开发技术
  • 脚本语言,如PHP, Python, Ruby等
  • 对多种浏览器的支持
底层高性能处理优化
  • 使用C、C++实现底层通信和IO优化

电子商务系统架构及技术特点
架构设计
关注数据的糅合(Mashup)
关系数据库与高性能NoSQL数据库结合
不固定的架构设计思路
  • 可能偏互联网方向,也可能偏企业系统方向
  • 分布式部署
事务缓存机制
  • 事务迁移、事务恢复、事务批量处理
较为严格的安全机制
  • 部分功能使用HTTPS及数字证书
与企业系统的对接交互
  • 与银行、支付平台的对接
  • 与企业订单系统、进销存系统、物流系统的对接

技术运用
有时效的缓存机制
  • 确保数据实时性与性能的平衡
大量数据挖掘和分析运用
  • 相关性分析
  • 定向推荐
部分运用商业中间件技术产品
  • 应用服务器
  • 业务流程管理
大量的开源技术运用
  • Java相关开源技术比较常见

使用IE9无法添加附件的解决方法 支持(0中立(0反对(0回到顶部