• 大规模并发 .(转)


    何谓大规模并发,不同层面有不同的理解
    企业应用(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相关开源技术比较常见 

  • 相关阅读:
    postgresql客户端连接错误的解决方法【转】
    在游戏开发中使用管理类的目的和作用
    Unity3D对象池
    yield的作用
    Unity延迟和重复调用方法
    Unity的Asset Store商店下载文件路径
    C#委托和事件详解
    C#一个关于委托和事件通俗易懂的例子
    C#委托和事件定义和使用
    C#委托和事件
  • 原文地址:https://www.cnblogs.com/huyinyang/p/3809225.html
Copyright © 2020-2023  润新知