解决方案_2017vs解决方案怎么添加解决方案 - CSDN
  • 大数据解决方案构建详解教程:1. 简单介绍Hadoop生态,介绍E-MapReduce产品,包括作业报警等。2. 探索Hadoop节约成本的几种方式3. 几大类大数据场景的解决方案4. 已有用户遇到的10大常见Hadoop问题剖析5. E-...
  • 一.动笔前先打一个电话  一般情况下,方案撰写人只是按照别人的要求提供方案,...所以动笔前先打几个电话,问清楚客户需求,这样不但可以提高方案的针对性,也可以获得大量的解决思路线索,对写方案大有好处。 二.努
    一.动笔前先打一个电话
        一般情况下,方案撰写人只是按照别人的要求提供方案,并非直接利用方案的人。所以在写方案之前,问问需要方案的同事,甚至是客户,听听他们对方案的想法和建议,这样对写方案会有很大帮助。
        闭门造车往往导致接受者对方案不满意,要求返工修改。所以动笔前先打几个电话,问清楚客户需求,这样不但可以提高方案的针对性,也可以获得大量的解决思路线索,对写方案大有好处。
    二.努力按客户业务逻辑写
        一般写方案最简单的方式就是按照协同软件设计思路和功能模块来写,因为有大量素材可用。但这样撰写方案并非是一种最佳选择,因为对客户而言,他必须转换角色进行思维,要站在供货商的思维模式上才能看懂方案字句之间的含义。
        如果从以客户为中心的角度出发,方案应尽量让客户容易看懂,好理解,自然也就取得了较好的印象分。
        方案应先仔细探讨客户业务,而不是将调研结论一一罗列,应从业务分析中推导出业务需求,最后描述技术实现手段。从这个意义上讲,解决方案要按照简明的业务手册来准备。
    三.按标准套路写方案
        同类型的方案都有自己的套路,例如可行性报告、解决方案、建议书等都各有套路。一个公司可以经常讨论完善和丰富方案的写作套路。我们应尽量按照标准套路准备方案,不要自成体系。在既定套路下发挥,套路就体现了一种结构化、体系化的思维模式,很多客户本身也是习惯阅读有套路的文档。

        套路和为客户定制并不矛盾,好的套路反映了专业文档定制的经验。

    四.先构思提纲,经过讨论,最后动笔

        很多时候方案的准备时间并不充分,很多人接到任务之后立即找个范本修改,这是不好的工作习惯。
        有时候利用模板的确可以较快地完成任务,但时间长了就形成了惰性,形成用替换方式抄改方案的习惯。真在实际工作中遇到个性化较强的项目,而标准供应链管理方案模板没有涵盖时就无从应对。这是因为平时写方案过程中思维始终缺少结构化思考练习的结果。
        写方案时一定不要急着动笔,而是先想提纲。提纲中的逻辑联系和业务衔接在脑海中推导得比较有力和充分了,才开始动笔;有了提纲,思路就不会断,写起来才快。
        如果有条件的话,这个思路还应该和大家讨论,特别是一些重要方案,一定要先反复讨论提纲。各种意见和思路在提纲中统一了,再动手写。这样就不至于遇到方案写完评审时又被否定,不得不推倒重来的痛苦。
    五.找一个安静的地方和完整的时间段开始
        写方案最怕中间不停地被打断,这样思路无法保持连贯性。所以无论接到多么紧急的方案编制任务,也不要急着去写,而是先把手头该处理的小事情处理干净,确保编写的时间段相对安静和完整,这样才能保证方案的质量。
        定要保证在一个时间段内初步拿出完整的推导思路和结构提纲,然后就可以逐步补充和丰富内容,不至于在写的过程中还为结构苦恼,不清楚从哪里下笔,每次要花费大量时间从头构思。
    六.认真准备方案的阅读提示和摘要
        客户决策领导往往公务繁忙,时间有限,很难保证将厚厚一本方案的内容全部认真研读,所以方案可以单独附一份摘要以供客户领导浏览。摘要重点介绍整个方案中的精华部分,当然也可以附带实施方法和典型用户介绍。通过摘要让方案的解决问题的思路在短短几页纸中得到清晰、准确的描述,这种用精炼文字描述业务思路的能力往往更能给人留下深刻印象
        对于较复杂、内容较多的方案一定要提供一份阅读提示,告诉不同的人其关心的内容可以通过阅读哪些章节直接获得。实际上很多论文和书籍序言都会有一段来说明文章的结构,读者可以直接进入感兴趣的话题,这对我们编制方案也是一个有益的启发。
    七.注意积累素材
        写方案时,无论按照何种客户业务组织材料,必然有80%的内容是相似的,毕竟软件设计理念不会在短期内发生巨大改变,方案涉及功能边界在短期内也不会发生大的改变,所以不同时期不同用户解决方案中很多素材是可以通用的。特别是一些公司通用素材,更是要随时注意积累、补充、完善和归类保存,只有在乎时多作有心人,在写方案时才不会因为缺少素材而将大量时间浪费在查找数据上。
        还要注意基本素材的运用要随时和公司的宣传口径保持一致,防止引用过期素材。标准素材库应由公司统一维护。
        获取素材的途径主要有:
        》现场初步需求调研与交流。
        》与熟悉类似项目的销售经理、技术支持工程师、实施工程师进行沟通。
        》与营销人员交流。
        》可收集的同行方案。
        》客户的网站。
        》相关行业的资料介绍。
        》行业书刊。
        例如客户企业介绍一般可以从客户的网站获取。从网站获取的客户企业介绍需经“角色转换”和“内容筛选”。角色转换是指站在软件公司的立场描述该客户的情况,要把第一人称改为第三人称。内容筛选是指主要介绍客户信息化的基础,包括客户的经济实力、管理水平、已完成和正在进行的信息化项目等内容,不要简单地复制粘贴。
        又如:行业战略分析可以从相关行业网站中寻找素材和灵感;对业务问题解决思路可以从同行方案中寻求素材和灵感,并结合自己的素材进行组织和提高。
    八.多写,然后熟能生巧
        写,勤写,主动积极地写。把每次写方案当作一次提高的机会。在这样的心态下才能写出好的方案。再好的经验也必须经过反复练习才能成为自己的习惯,养成良好的方案撰写习惯也是反复练习的成果。
        寻求回馈意见,持续改进
        很多人写完方案后,就觉得任务完成了,是成是败,已经过去。
        但对于一个想写一流方案的人,每次电子商务方案提交后一定要征询相关人员的看法和意见,对于认为写得好的回馈信息,要分析究竟好在哪里,遇到同样情况时,可以有意识地借鉴;对于回馈不好的意见,要力求在下次进行改善。通过有意识地扬长避短,方案就能日见精练,更能打动客户。
        真正有志于写出完美方案的人,对自己的方案是永远不会满意的,也只有这样,才会每次进步一点,解决方案的质量才会不断提高。
    展开全文
  • 4 技术实现方案 4.1 总体设计 4.2 安全体系建设 4.3 数据库结束 4.4 开发中工具的使用 4.5 开发规范 5 项目实施进度与人员配置 5.1 项目实施进度计划 5.2 组织结构 5.3 人员配置
  • 大数据平台解决方案

    2018-02-14 00:07:54
    第1章 华数大数据分析平台方案介绍 1.1 华数大数据平台总体架构 1.1.1 华数大数据平台应用架构  应用架构图 基于华数多年来的开发经验,并借鉴行业大数据分析平台的实施、管理和应用方面的成功...

    第1章 华数大数据分析平台方案介绍

    1.1 华数大数据平台总体架构

    1.1.1 华数大数据平台应用架构

      应用架构图

    基于华数多年来的开发经验,并借鉴行业大数据分析平台的实施、管理和应用方面的成功经验,结合禾丰牧业实际信息化情况,我们将禾丰大数据平台实际为三层架构,其中:

    l基础数据源层:目前禾丰牧业所应用的数据主要来源于业务系统(EAS)与平面文本文件(Excel)两种类型,结合未来信息化的发展,音频数据和视频数据等越来越丰富的数据类型也将陆续纳入到我们的大数据平台体系之中,因此为保证我们的大数据平台的先进性,要能支持多种类型的数据源;l大数据处理层:由于数据源类型的多样性,传统关系型数据仓库架构或者分布式存储架构各有优缺点,单独使用都无法很好的满足对结构化和非结构化数据的存储和应用需求,因此我们建议采用传统数据仓库架构与大数据分布式数据仓库架构两者相结合的架构设计,两者紧密配合共同承担大数据处理任务,为大数据应用提供数据接口、数据交换、数据查询、数据分析和数据挖掘提供数据基础;l大数据应用层:随着信息化的发展,对大数据的应用方式也越来越多,大数据分析平台应用层需要满足诸如:固定报表、OLAP分析、KPI分析、指标监控、即席查询(自助式分析)、决策支持、邮件推送、office集成、移动BI、预警预测(数据挖掘)等多种展现方式。

    1.1.2禾丰大数据平台技术架构

     

    技术架构图

    根据我们实施建设大数据分析平台多年的经验,结合禾丰牧业三层式数分析平台系统构架,通过数据采集(包括数据源)、信息存储与管理(数据仓库和Hadoop)和信息共享三部分技术来实现。 l数据采集:

    1)结构化数据采集:禾丰牧业现有的数据主要来自于EAS系统、青软系统、电商平台和文本文件都属于结构化数据,大数据分析平台采用ETL工具-kettle作为采集结构化数据的手段。ETL(Extract, Transform, Load)是建立大数据分析平台的重要组成部分,它将大数据分析平台中所需的数据按数据仓库建立的方法每天或定期从各个业务系统中采集详尽的业务数据,并根据各自的需求进行数据调整,数据迁移过程中需将原始数据进行抽取、清洗、合并和装载。在此过程中必须保证数据的完备性和数据的一致性。当业务数据量过大,未避免Mysql数据仓库压力过大,亦可将业务数据通过kettle迁移到hadoop平台的数据库Hbase中。

    2)非结构化数据采集:随着禾丰牧业信息化建设的发展,未来电话会议、视频会议、影音文件、微博实时数据、传感器采集的设备数据、移动端收集的数据以及其他流数据等非结构化数据,我们将通过传感器接口、视频接入设备、网络爬虫工具和流处理程序等方式分别进行采集并存储到HDFS和Hbase中。l大数据存储和管理:

    1)结构化数据存储和管理:为方便其管理和满足未来展现的性能要求,我们选择以关系型数据库MySQL和hadoop的HBase数据库共同承担对结构化的数据的存储和管理。以MySQL建立传统数据仓库来实现对用于结构化数据和元数据的集中存储与管理,并根据需求建立面向部门和主题的数据集市,中央数据仓库将被划分为三个逻辑存储区间: ODS(Operational Data Store)、DW(Data Warehourse)、DM(Data Mart):ODS将存放各业务系统的原始数据,包括与原结构相同的业务数据以及经过初步整理后的业务数据;DW区域存放经过整理过的数据,是大数据分析平台真正的数据中心;DM区域存放各个应用系统(web应用、BI、OLAP、Data Mining等)所需的综合数据。与此同时我们在MySQL和HBase数据库之间建立连接,利用Kettle定时进行数据交换,俩种数据仓库共同大数据应用提供数据支撑,从而实现数据共享,分摊压力和数据备份的目的。

    2)非结构化数据存储和管理:由于Mysql不支持对非结构化数据的存储,我们利用大数据应用框架Hadoop平台的数据仓库作为传统数据仓库的补充,实现对非结构化数据的存储和管理,并对来自网络的海量数据查询提供支撑。Hadoop平台集中了很多功能组件,其中HDFS是分布式文件系统,用于分布式存储大数据文件;Hbase是可扩展的分布式列存储NoSQL数据库,用于存储结构化和非结构化数据;Hive是基于Hadoop的数据仓库工具,可以存储、查询和分析存储在HBase中的数据;Mapreduce是用于对Hadoop平台大规模数据集进行并行查询的编程模型;Pig 是一个高级过程语言,适合于使用 Hadoop 和 MapReduce 平台来查询大型半结构化数据集。l应用与分析:大数据分析平台为满足不同用户的需求,需要提供多种不同的应用与分析方式,大数据分析平台提供三种应用方式。第一种:支持利用java或C等开发语言编写程序实现对Hadoop平台和MySQL数据仓库中数据的应用;第二种:我们选用强大的商务智能软件IBM-Cognos作为信息共享工具。Cognos作为多样化的前端分析展示工具,支持建立DMR和OLAP两种模型,提供了在线报表、OlAP分析、仪表板、记分卡、即席查询、邮件分发、Office集成、移动APP等多种信息共享技术。第三种:我们选用” 统计产品与服务解决方案”软件IBM-SPSS作为数据挖掘工具,SPSS支持以Hadoop平台和MySQL搭建挖掘模型,用于统计学分析运算、数据挖掘、预测分析和决策支持任务,支持描述性统计、均值比较、一般线性模型、相关分析、回归分析、对数线性模型、聚类分析、数据简化、生存分析、时间序列分析、多重响应等多类统计分析和挖掘算法。

    展开全文
  • 技术架构 分布式架构云平台在充分分析IT技术发展趋势,遵循集中化、标准化、集成化、可靠化和可扩展化的设计原则,以价值创造为使命,以规范化、一体化、智能化的云平台为支撑,实现信息的透明共享、业务的敏捷协同...

    技术架构

    分布式架构云平台在充分分析IT技术发展趋势,遵循集中化、标准化、集成化、可靠化和可扩展化的设计原则,以价值创造为使命,以规范化、一体化、智能化的云平台为支撑,实现信息的透明共享、业务的敏捷协同、管控及时、决策科学为设计目标,选择传统成熟的J2EE、SOA、应用集成和BI信息技术和新一代的云计算、大数据、移动应用信息技术相结合的技术路线。

    分布式架构云平台规划设计了集约化、云架构动态配置的企业IT基础设施;

    • 共享化、集中数据存储管理的企业数据资源服务;

    • 组件化、平台化、柔性集成的企业应用支撑服务;

    • 标准化、服务化、整合智能的企业业务应用服务;

    一站式、多终端服务的企业信息展示交互服务等技术层,每层又包括若干成熟稳定的技术组件,各技术层,自下而上,层层支撑,各技术组件松散耦合,互联互通,科学高效,易于扩展,减少了信息孤岛,增强了系统的标准化和集约化,优化了系统的用户体验,提高工作效率。

    阿里云解决方案架构师,讲述分布式架构云平台解决方案(附图文)

    分布式架构云平台技术设计原则

    • 先进性原则

    在整体设计和实现上,依托云计算、大数据领域的知名开源项目(如Hadoop、Spark、OpenStack等)。由于遵循了业界广泛认可的事实标准,可以充分借力全球生态圈的资源,推动软硬件分层解耦,不断提升兼容性。兼容多种异构物理设备,避免厂商绑定。数据层面,支持多种数据源,包括结构化/非结构化类型的数据处理,数据本身、数据计算也都支持开放共享。优先采用先进成熟的技术组件,搭建稳定并且高效的大数据云计算管理平台,并在平台基础上实现大规模的数据采集与分析的相关业务应用。平台设计以满足当前的业务功能为主,兼顾考虑未来发展的趋势。

    • 可靠性原则

    可靠性包括整体可靠性、数据可靠性和单一设备可靠性三个层次。通过大数据云计算平台的分布式计算、存储架构,从整体系统上提高可靠性,降低系统对单设备可靠性的要求;平台设计方面保证基于hadoop和虚拟化的集群系统平台的稳定与高效,提供针对现有底层硬件设备的Hadoop和虚拟化相关技术组件的调优,以及对于整体集群的配套监控系统的搭建和集群维护与管理等相关方案;应用设计方面采用明确的应用分层架构,一方面可实现上层数据应用与底层基础数据的依赖分离,实现应用架构上的解耦;另一方面可提高上层数据的分析效率与降低运行成本。采用相关的容错技术和故障处理技术,保证数据应用的安全可靠,保证数据分析平台可用性达到使用要求。

    • 安全保密性

    采用统一的用户认证,统一的用户、权限管理和控制、密码控制等多种安全和保密措施。为保证信息的安全性,对内部网上的信息建立符合安全要求的防火墙、入侵检测、数字证书、防病毒、数据加密技术等,能够严格有效地防止外来非法用户入侵,能够避免遭受网络攻击,防止失密情况的发生,防止非法侵入带来的损失。

    • 可扩展性

    应用开发平台采用模块化建设和扩展模式。支持小规模起步,线性扩展,以满足不同场景,不同投资计划和规模的要求;随着数据规模的扩大、应用的完善,现在数据平台能够在不影响当前用户正常使用的情况下,灵活、方便地进行集群扩容。

    • 开放性

    云计算平台是在成熟落地的方案上完全自主研发,主要应用开源技术。

    分布式关键技术

    阿里云解决方案架构师,讲述分布式架构云平台解决方案(附图文)

    • 微服务

    将系统功能划分为最小服务单元,完成单一功能,每个服务独立部署,服务间通过互相调用形成完整业务逻辑。主要特点:

    -高内聚、低耦合

    -开闭原则

    -高效率

    -弹性计算

    • 分布式事务

    通过消息机制和分布式锁实现分布式事务,在微服务架构中保证业务逻辑的完整性。主要特点:

    -消息队列

    - 原子操作

    - 回滚机制

    • 跨机器调用

    将任务分配在更多的节点上去运行,跨机器的调用取代原来单个节点内、进程内的调用。主要特点:

    - 多节点化

    - 同步+异步

    • 伸缩与容错

    横向扩展代替纵向扩展,使得伸缩性变得更好,整体容错性大大提升。主要特点:

    - 一致性哈希

    - 多副本

    平台关键组件

    阿里云解决方案架构师,讲述分布式架构云平台解决方案(附图文)

    • 企业服务总线

    采用Dubbo+Zookeeper技术作为企业服务总线,对所有微服务进行管理,服务总线具有以下特点:

    - 自动发现和注册服务,即插即用。

    - 可为微服务提供负载均衡策略,需要其他负载均衡软件。

    - 统计与监控服务调用情况并记录响应时间。为程序调优及扩展提供统计数据。

    • 消息队列

    平台的消息队列采用Kafka技术,Kafka是高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。主要用于:

    - 服务之间的消息通讯,实现完整的业务逻辑。

    - 提供大并发业务的队列服务,避免大并发下服务崩溃问题。

    • 分布式文件系统

    平台采用HDFS和FastDFS的分布式文件系统。

    HDFS主要解决超大文件的存储(如日志文件、视频文件等)及HBase等大数据存储。主要分为NameNode和DataNode,NameNode存储文件的META信息,DataNode存储数据块。客户端调用时从Name节点读取到文件的多个数据块信息,从多台服务器上获取后合并为一个文件。FastDFS是轻量级的分布式文件解决方案,主要解决存储海量小文件,如上传图片、上传文件、资源文件等等海量的小文件,这些文件不适合HDFS存储,所以采用FastDFS存储。

    • 云服务器IAAS

      平台采用OpenStack系列技术,支持Xen/KVM/Hyper-V/ESX等虚拟化技术。为分布式和大数据提供弹性计算服务。

     

    想要提升技术的朋友,欢迎加QQ群:190469800,大家一起学习,相互讨论。群内已经将资料(源码,笔记,PPT,学习视频)整理好了,欢迎加群领取。希望能够帮助到你们。不是Java程序员也没关系,帮忙转发给更多朋友!谢谢。

     

     

    展开全文
  • 高并发的解决方案

    2018-08-19 11:11:46
      1.应用和静态资源分离 刚开始的时候应用和静态资源是保存在一起的,当并发量达到一定程度的时候就需要将静态资源保存到专门的服务器中,静态资源主要包括图片、视频、js、css和一些资源文件等,这些文件因为...

     

     

    1.应用和静态资源分离

    刚开始的时候应用和静态资源是保存在一起的,当并发量达到一定程度的时候就需要将静态资源保存到专门的服务器中,静态资源主要包括图片、视频、js、css和一些资源文件等,这些文件因为没有状态所以分离比较简单,直接存放到响应的服务器就可以了,一般会使用专门的域名去访问。
    通过不同的域名可以让浏览器直接访问资源服务器而不需要再访问应用服务器了。架构图如下:

    这里写图片描述

    2.页面缓存

    页面缓存是将应用生成的页面缓存起来,这样就不需要每次都生成页面了,从而可以节省大量的CPU资源,如果将缓存的页面放到内存中速度就更快了。如果使用Nginx服务器就可以使用它自带的缓存功能,当然也可以使用专门的Squid 服务器。页面缓存的默认失效机制一班都是按缓存时间处理的,当然也可以在修改数据之后手动让相应的缓存失效。
    页面缓存主要是使用在数据很少发生变化的页面,但是很多页面是大部分数据都很少发生变化,而其中很少一部分数据变化频率却非常高,比如说一个显示文章的页面,正常来说完全可以静态化,但是如果文章后面有“顶”和“踩”的功能而且显示的有响应的数量,这个数据的变化频率就比较高了,这就会影响静态化。这个问题可以用先生成静态页面然后使用Ajax来读取并修改响应的数据,这样就可以一举两得来,既可以使用页面缓存也可以实时显示一些变化频率高的数据来。

    其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。

    除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。

    同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。

    3.集群与分布式

    集群是每台服务器都具有相同的功能,处理请求时调用那台服务器都可以,主要起分流作用。

    分布式是将不同的业务放到不同的服务器中,处理一个请求可能需要用到多台服务器,这样就可以提高一个请求的处理速度,而且集群和分布式也可以同时使用。

    集群有两个方式:一种是在静态资源集群。另一种是应用程序集群。静态资源集群比较简单。应用程序集群在处理过程中最核心的问题就是Session 同步问题。

    Session 同步有两种处理方式:一种是在Session 发生变化后自动同步到其他服务器,另一种就是用个程序统一管理Session。所有集群的服务器都使用同一个Session,Tomcat 默认使用就是第一种方式,通过简单的配置就可以实现,第二种方式可以使用专门的服务器安装Mencached等高效的缓存程序统一来管理session,然后再应用程序中通过重写Request并覆盖getSession 方法来获取制定服务器中的Session。

    对于集群来说还有一个核心的问题就是负载均衡,也就是接收到一个请求后具体分配到那个服务器去处理的问题,这个问题可以通过软件处理也可以使用专门的硬件(如:F5)解决。

    这里写图片描述

    4. 反向代理

    反向代理指的是客户端直接访问的服务器并不真正提供服务,它从别的服务器获取资源然后将结果返回给用户。

    图:

    这里写图片描述

    4.1 反向代理服务器和代理服务器的区别

    代理服务器的作用是代我门获取想要的资源然后将结果返回给我们,所要获取的资源是我门主动告诉代理服务器的,比如,我门想访问Facebook,但是直接访问不了,这时就可以让代理服务器访问,然后将结果返回给我们。

    反向代理服务器是我门正常访问一台服务器的时候,服务器自己去调用了别的服务器资源并将结果返回给我们,我门自己并不知道。

    代理服务器是我们主动使用的,是为我们服务的,他不需要有自己的域名;反向代理服务器是服务器自己试用的,我门并不知道,它有自己的域名,我门访问它和访问正常的网址没有任何区别。

    反向代理服务器主要有三个作用: 
    1. 可以作为前端服务器跟实际处理请求的服务器集成; 
    2. 可以做负载均衡 
    3. 转发请求,比如说可以将不同类型的资源请求转发到不同的服务器去处理。

    5. CDN

    cdn其实是一种特殊的集群页面缓存服务器,他和普通集群的多台页面缓存服务器相比,主要是它存放的位置和分配请求的方式有点特殊。CDN 服务器是分布在全国各地的,当接收到用户请求后会将请求分配到最合适的CDN服务器节点获取数据。比如联通的用户分配到联通的节点,上海的用户分配到上海的节点。

    CDN的每个节点其实就是一个页面缓存服务器,如果没有请求资源的缓存就会从主服务器获取,否则直接返回缓存的页面。

    CDN分配请求(负载均衡)的方式是用专门的CDN域名解析服务器在解析域名的时候就分配好的。一般的做法是在ISP哪里试用CNAME将域名解析到一个特定的域名,然后再将解析到的那个域名用专门的CDN服务器解析道相应的CDN节点。如图。

    这里写图片描述

    第二步访问CDN的DNS服务器是应为CNAME记录的目标域名使用NS记录指向了CDN的DNS服务器。CDN的每个节点可能也是集群了多台服务器。

    6. 底层的优化

    前面说的所有都是架构都是建立在最前面介绍的基础结构之上的。很多地方都需要通过网络传输数据,如果可以加快网络传输的速度,那将会让整个系统得到改善。

     

    7.数据库集群和库表散列

    大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

    在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。

    上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

    8. 小结

    网站架构的整个演变过程主要是围绕大数据和高并发这两个问题展开的,解决方案主要分为使用缓存和多资源两种类型。多资源主要指多存储(包括多内存)、多CPU和多网络,对于多资源来说又可以分为单个资源处理一个完整的请求和多个资源合作处理一个请求两种类型,如多存储和多CPU中的集群和分布式,多网络中的CDN和静态资源分离。理解了整个思路之后就抓住了架构演变的本质,而且自己可能还可以设计出更好的架构。

     

    其它简单总结:

    首先,我认为解决问题之前首先要有清晰的思路,如果只是用来别人的解决方案那也只能是拿来主义,没有真正理解,没有做到举一反三。

    海量数据和高并发经常被连在一块说事儿,虽然他们完全是两回事儿。海量数据纯指的是数据库的海量数据,而并发指的却包括数据库和服务器的高访问量。

    那么问题来了,既然是数据库的数据量大,那怎么办呢?要想解决问题,首先要知道问题是什么!!!那么海量数据会给我带来什么样的问题呢?

    海量数据带来的问题无非就是增删改查的问题,除了之外还能有啥问题呢?总不能是带来安全问题吧(打脸一,还真有可能是安全问题)

    1 数据库访问缓慢

    2 插入更新缓慢,这个问题只能通过分库分表解决

    要解决数据库访问缓慢的问题还有几种方法,既然访问数据库慢的话,在逻辑允许的情况下可以不访问数据库呢?

    1 使用缓存

    2 使用页面静态化

    既然不访问数据库逃不过去了,那我们就对数据库进行优化

    3 优化数据库(包含的内容非常多,比如参数配置,索引优化,sql优化等等)

    4 分离数据库中活跃的数据

    5 读写分离

    6 批量读取和延迟修改;

    7 使用搜索引擎搜索数据库中的数据;

    8 使用NoSQL和Hadoop等技术;

    9 进行业务的拆分;

     

    高并发的解决方案

    其实这个问题必须结合上面的海量数据来讨论,什么情况下会出现高并发呢?一定是平时访问量就比较大的情况,那么平时访问量比较大相应的数据存储也就越来越多,这都是相辅相成的,当然也有个例,比如刚需,比如12306,这里的高并发相比于它的数据来说已经不算海量了。那么平时访问量大如何解决呢?因为这里牵扯到服务器和数据库的问题,所以要从这两方面来进行优化

    1 增加web服务器数量,也就是做集群,做负载均衡。既然一台服务器无法完成任务,那就多用几台,几台不够用机房

     在通向第二种解决方法之前,还有没有除了数据库服务器之外能做的一些优化手段呢?当然有

    1.1 页面缓存

    1.2 cdn

    1.3 反向代理

    1.4 应用程序和静态资源分离(比如专供下载的资源单独放在一起,给这台服务器提供很高的带宽资源)

    2 增加数据库服务器数量,同样做集群,做负载均衡。

     

     

    海量数据的解决方案

    1 使用缓存

    好多事情都是相辅相成的,相比来说使用缓存更多是用来解决高并发问题的,因为海量数据导致了访问的缓慢,容易造成高并发问题的严重性,又因为数据库一般是web访问的瓶颈,所以我们在业务逻辑允许的情况下尽量先避免操作数据库,于是,就有了缓存。将必要的数据存放在内存中,而不必每次都去数据库中读取造成不必要的性能浪费和加快访问速度---这就是缓存带来的好处。那使用缓存以及选用管理缓存软件时应该注意些什么东西呢?

    2 页面静态化---不想解释,还有什么值得去解释呢?

    3 数据库优化

    3.1 数据库表结构涉及

    3.2 数据类型的选用

    3.3 sql优化

    3.4 索引优化

    3.5 配置优化

    需要注意的地方实在太多,应该作为单独的一章拿出来讲

    4 分离数据库中的活跃数据

    为什么要分离呢?说一个我实际环境中遇到的问题吧!有一个表只有10几个字段,表有130万条数据,但大小已经到了5G的数据,这本身是不太合理的,这么少的数据占用了太多的数据,说明其中有些字段存储了大量的字符串(比如说文章内容等),每次检索这个表时大部分是用不到这些大字段内容的,但却需要耗时比较长,产生很多的慢日志。这时我们可以考虑将表进行垂直切分,将活跃数据分离开来,这样能大大加快访问速度

    5 读写分离

    展开全文
  • 什么是秒杀秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品,电商网站一般会在约定时间点对其进行限量销售,因为这些商品的特殊性,会吸引大量用户...

    【高并发解决方案】1、高并发解决方案汇总

    一、对于被频繁调用,更新频率较低的页面,可以采用HTML静态化技术

    二、图片服务器分离

    三、数据库集群和库表散列

          mysql主从。m-m-s-s-s...(2个主,多个从。多个从使用负载均衡。主写入数据,从读取数据)

    四、缓存。众多的缓存框架

    五、负载均衡。nginx,lvs,F5

    六、搜索用单独的服务器,搜索框架

    七、使用MQ服务器

    【高并发解决方案】2、集群概述

    1.什么是集群

    集群是一组协同工作的服务实体,用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来,一个集群就象是一个服务实体,但 事实上集群由一组服务实体组成。

    2.集群的特性 
    与单一服务实体相比较,集群提供了以下两个关键特性: 
    1.可扩展性--集群的性能不限于单一的服务实体,新的服 务实体可以动态地加入到集群,从而增强集群的性能。 
    2. 高可用性--集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中,同样的服务可以由多个服务实体提供。如果一个服务实体失败了,另一个服务实体会接管失败的服务实体。集群提供的从一个出 错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。 
    为了具有可扩展性和高可用性特点,集群的必须具备以下两大能力: 
    (1) 负 载均衡--负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。 
    (2) 错误恢复--由于某种原因,执行某个任务的资源出现故障,另一服 务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作,另一个实体中的资源透明的继续完成任务的过程叫错误恢复。 
    负载均衡 和错误恢复都要求各服务实体中有执行同一任务的资源存在,而且对于同一任务的各个资源来说,执行任务所需的信息视图(信息上下文)必须是一样的。

     

    3 集群的分类 
    集群主要分成三大类:高可用集群(High Availability Cluster/HA), 负载均衡集群(Load Balance Cluster),高性能计算集群(High Performance Computing Cluster/HPC) 
    (1) 高可用集群(High Availability Cluster/HA):一般是指当集群中有某个节点失效的情况下,其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线,该过程并不影响整个集群的运行。常见的就是2个节点做 成的HA集群,有很多通俗的不科学的名称,比如"双机热备", "双机互备", "双机",高可用集群解决的是保障用户的应用程序持续对外提供服 务的能力。 
    (2) 负载均衡集群(Load Balance Cluster):负载均衡集群运行时一般通过一个或者多个前端负载均衡器将工作负载分发到后端的一组服务器上,从而达到将工作负载分发。这样的计算机集群有时也被称为服务器群(Server Farm)。一般web服务器集群、数据库集群 和应用服务器集群都属于这种类型。这种集群可以在接到请求时,检查接受请求较少,不繁忙的服务器,并把请求转到这些服务器 上。从检查其他服务器状态这一点上 看,负载均衡和容错集群很接近,不同之处是数量上更多。 
    (3) 高性能计算集群(High Performance Computing Cluster/HPC):高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力,因而主要应用在科学计算领域。这类集群致力于提供单个计算机所不能提供的强大的计算能力

    【高并发解决方案】3、消息队列软件产品大比拼

    转自:http://www.oschina.net/news/17973/message-queue-shootout

    我花了一周的时间评估比较了一下各种消息队列产品,非常的有趣。我做这个事的动机是因为一个客户有一个很高性能需求。他们的消息信息突破了1百万个并发。目前他们使用的是SQL server,并不理想,我建议他们使用消息队列服务器。

    为了对一些相似的候选产品获得一个全面的但是粗浅的性能上的了解,我们它们放在一起做了个测试。我让每个消息产品各发送和接受1百万千条1K的消 息。测试准备的有些仓促,我并没有修改任何的配置,只是快速的看了一下它们的安装文档,安装好每种软件,然后就让它们做这些最简单的收发信息的操作。所以 这是一次真正的“开箱即装即用”的性能表现。我完全理解,这对那些初始配置十分保守的消息队列产品将会是个惩罚。

    候选产品有:

    • MSMQ.
      这是微软的产品里唯一被认为有价值的东西。对我的客户来说,如果MSMQ能证明可以应对这种任务,他们将选择使用它。关键是这个东西并不复杂,除了接收和 发送,没有别的;它有一些硬性限制,比如最大消息体积是4MB。然而,通过和一些像MassTransit 或 NServiceBus这样的软件的连接,它完全可以解决这些问题。
    • ActiveMQ.
      Java世界的中坚力量。它有很长的历史,而且被广泛的使用。它还是跨平台的,给那些非微软平台的产品提供了一个天然的集成接入点。然而,它只有跑过了MSMQ才有可能被考虑。
    • RabbitMQ.
      我听说了很多关于这个用Erlang写成的消息中间件的优秀的特性。它支持开放的高级消息队列协议 (AMQP,Advanced Message Queuing Protocol),从根本上避免了生产厂商的封闭,使用任何语言的各种客户都可以从中受益。这种协议提供了相当复杂的消息传输模式,所以基本上不需要 MassTransit 或 NServiceBus 的配合。它还具有“企业级”的适应性和稳定性。这些东西对我的客户来说十分的有吸引力。
    • ZeroMQ.
      我在研究AMQP时从发现了这个产品。开发这个产品的公司是AMQP集团的一部分,并且还有一个叫做OpenAMQ的产品。然而,他们却戏剧性的从AMQP分离的出去,并抱怨说这这个产品迷失了方向、变的越来越复杂。你可以到这里阅 读Dear John的关于此事的文章。ZeroMQ具有一个独特的非中间件的模式,也就是说,跟其它几个接受测试的产品不同,你不需要安装和运行一个消息服务器,或 中间件。你只需要简单的引用ZeroMQ程序库,可以使用NuGet安装,然后你就可以愉快的在应用程序之间发送消息了。非常有趣的是,他们也同样使用这 方式在任何利用ZeroMQ进行强大的进程内通信的语言里创建Erlang风格的这种执行角色。

    把这四个MQ产品装上、跑起来是一个很有趣的工作。当你需要安装一个非Windows平台的产品时,下一定的功夫那是必须的。ActiveMQ需要 在目标机器上安装Java,RabbitMQ需要Erlang环境。安装这两个产品都没有遇到麻烦,但我想这是否给系统的维护增加了一层任务。如果这个中 的一个被选中,我需要让系统维护的人去理解和维护他们以前不熟悉的运行库。ActiveMQ,
    RabbitMQ 和 MSMQ 都需要启动服务进程,这些都可以监控和配置,另外一个就有问题了。

    ZeroMQ,它没有中间件架构,不需要任何服务进程和运行时。事实上,你的应用程序端点扮演了这个服务角色。这让部署起来非常简单,但担心的是, 你没有地方可以观察它是否有问题出现。就目前我知道的,ZeroMQ仅提供非持久性的队列。你可以在需要的地方实现自己的审计和数据恢复功能。老实说,我 甚至不确信是否该把它列在此次测试中,它的运行原理和其它几种差别太大了。

    我就不瞎扯了,下面是测试结果。显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。

    Message Queue

    就像你看到的,ZeroMQ和其它的不是一个级别。它的性能惊人的高。公平的说,ZeroMQ跟其它几个比起来像头巨兽,尽管这样,结论很清楚:如果你希望一个应用程序发送消息越快越好,你选择ZeroMQ。当你不太在意偶然会丢失某些消息的情况下更有价值。

    老实讲,我更希望使用Rabbit。但这种事情是应该做更多的测试,你最终会有一个最爱,我所听到的、读到的各种关于Rabbit的事情让我觉得它应该是最佳选择。但使用这个测试结果,我很难说服他们不去使用MSMQ。

    如果你想自己跑一下这些测试,我的测试代码都放在了GitHub上。我很感兴趣(但不是非常非常感兴趣)想知道如何优化这些测试,所以,如果你能做到一个更好的测试结果,请告诉我。谢谢。


    【高并发解决方案】如何设计一个秒杀系统

    什么是秒杀

    秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品,电商网站一般会在约定时间点对其进行限量销售,因为这些商品的特殊性,会吸引大量用户前来抢购,并且会在约定的时间点同时在秒杀页面进行抢购。

    秒杀系统场景特点

    • 秒杀时大量用户会在同一时间同时进行抢购,网站瞬时访问流量激增。
    • 秒杀一般是访问请求数量远远大于库存数量,只有少部分用户能够秒杀成功。
    • 秒杀业务流程比较简单,一般就是下订单减库存。

    秒杀架构设计理念

    限流: 鉴于只有少部分用户能够秒杀成功,所以要限制大部分流量,只允许少部分流量进入服务后端。

    削峰:对于秒杀系统瞬时会有大量用户涌入,所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因,所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

    异步处理:秒杀系统是一个高并发系统,采用异步处理模式可以极大地提高系统并发量,其实异步处理就是削峰的一种实现方式。

    内存缓存:秒杀系统最大的瓶颈一般都是数据库读写,由于数据库读写属于磁盘IO,性能很低,如果能够把部分数据或业务逻辑转移到内存缓存,效率会有极大地提升。

    可拓展:当然如果我们想支持更多用户,更大的并发,最好就将系统设计成弹性可拓展的,如果流量来了,拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。

    架构方案

    一般秒杀系统架构

    这里写图片描述

    设计思路

    将请求拦截在系统上游,降低下游压力:秒杀系统特点是并发量极大,但实际秒杀成功的请求数量却很少,所以如果不在前端拦截很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时。 
    充分利用缓存:利用缓存可极大提高系统读写速度。 
    消息队列:消息队列可以削峰,将拦截大量并发请求,这也是一个异步处理过程,后台业务根据自己的处理能力,从消息队列中主动的拉取请求消息进行业务处理。

    前端方案

    浏览器端(js):

    页面静态化:将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素。通过CDN来抗峰值。 
    禁止重复提交:用户提交之后按钮置灰,禁止重复提交 
    用户限流:在某一时间段内只允许用户提交一次请求,比如可以采取IP限流

    后端方案

    服务端控制器层(网关层)

    限制uid(UserID)访问频率:我们上面拦截了浏览器访问的请求,但针对某些恶意攻击或其它插件,在服务端控制层需要针对同一个访问uid,限制访问频率。

    服务层

    上面只拦截了一部分访问请求,当秒杀的用户量很大时,即使每个用户只有一个请求,到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机,服务层并发请求压力至少为100W。

    1. 采用消息队列缓存请求:既然服务层知道库存只有100台手机,那完全没有必要把100W个请求都传递到数据库啊,那么可以先把这些请求都写到消息队列缓存一下,数据库层订阅消息减库存,减库存成功的请求返回秒杀成功,失败的返回秒杀结束。

    2. 利用缓存应对读请求:对类似于12306等购票业务,是典型的读多写少业务,大部分请求是查询请求,所以可以利用缓存分担数据库压力。

    3. 利用缓存应对写请求:缓存也是可以应对写请求的,比如我们就可以把数据库中的库存数据转移到Redis缓存中,所有减库存操作都在Redis中进行,然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

    数据库层

    数据库层是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承担“能力范围内”的访问请求。所以,上面通过在服务层引入队列和缓存,让最底层的数据库高枕无忧。

    案例:利用消息中间件和缓存实现简单的秒杀系统

    Redis是一个分布式缓存系统,支持多种数据结构,我们可以利用Redis轻松实现一个强大的秒杀系统。

    我们可以采用Redis 最简单的key-value数据结构,用一个原子类型的变量值(AtomicInteger)作为key,把用户id作为value,库存数量便是原子变量的最大值。对于每个用户的秒杀,我们使用 RPUSH key value插入秒杀请求, 当插入的秒杀请求数达到上限时,停止所有后续插入。

    然后我们可以在台启动多个工作线程,使用 LPOP key 读取秒杀成功者的用户id,然后再操作数据库做最终的下订单减库存操作。

    当然,上面Redis也可以替换成消息中间件如ActiveMQRabbitMQ等,也可以将缓存和消息中间件 组合起来,缓存系统负责接收记录用户请求,消息中间件负责将缓存中的请求同步到数据库。

    【高并发解决方案】6、数据库水平切分的实现原理解析

     

    第1章 引言

    随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能,横向扩展数据层已经成为架构研发人员首选的方式。

    • 水平切分数据库:可以降低单台机器的负载,同时最大限度的降低了宕机造成的损失;
    • 负载均衡策略:可以降低单台机器的访问负载,降低宕机的可能性;
    • 集群方案:解决了数据库宕机带来的单点数据库不能访问的问题;
    • 读写分离策略:最大限度了提高了应用中读取数据的速度和并发量;

    第2章 基本原理和概念

    什么是数据切分

    "Shard" 这个词英文的意思是"碎片",而作为数据库相关的技术用语,似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。通过一系列的切分规则将数据水平分布到不同的DB或table中,在通过相应的DB路由或者table路由规则找到需要查询的具体的DB或者table,以进行Query操作。“sharding”通常是指“水平切分”,这也是本文讨论的重点。接下来举个简单的例子:我们针对一个Blog应用中的日志来说明,比如日志文章(article)表有如下字段:

    面对这样的一个表,我们怎样切分呢?怎样将这样的数据分布到不同的数据库中的表中去呢?我们可以这样做,将user_id为1~10000的所有的文章信息放入DB1中的article表中,将user_id为10001~20000的所有文章信息放入DB2中的 article表中,以此类推,一直到DBn。这样一来,文章数据就很自然的被分到了各个数据库中,达到了数据切分的目的。

    接下来要解决的问题就是怎样找到具体的数据库呢?其实问题也是简单明显的,既然分库的时候我们用到了区分字段user_id,那么很自然,数据库路由的过程当然还是少不了user_id的。就是我们知道了这个blog的user_id,就利用这个user_id,利用分库时候的规则,反过来定位具体的数据库。比如user_id是234,利用刚才的规则,就应该定位到DB1,假如user_id是12343,利用该才的规则,就应该定位到DB2。以此类推,利用分库的规则,反向的路由到具体的DB,这个过程我们称之为“DB路由”。

    平常我们会自觉的按照范式来设计我们的数据库,考虑到数据切分的DB设计,将违背这个通常的规矩和约束。为了切分,我们不得不在数据库的表中出现冗余字段,用作区分字段或者叫做分库的标记字段。比如上面的article的例子中的user_id这样的字段(当然,刚才的例子并没有很好的体现出user_id的冗余性,因为user_id这个字段即使就是不分库,也是要出现的,算是我们捡了便宜吧)。当然冗余字段的出现并不只是在分库的场景下才出现的,在很多大型应用中,冗余也是必须的,这个涉及到高效DB的设计,本文不再赘述。

    为什么要数据切分

    上面对什么是数据切分做了个概要的描述和解释,读者可能会疑问,为什么需要数据切分呢?像 Oracle这样成熟稳定的数据库,足以支撑海量数据的存储与查询了?为什么还需要数据切片呢?

    的确,Oracle的DB确实很成熟很稳定,但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑,这是一般公司能支付的起的吗?即使就是能支付的起,假如有更好的方案,有更廉价且水平扩展性能更好的方案,我们为什么不选择呢?

    我们知道每台机器无论配置多么好它都有自身的物理上限,所以当我们应用已经能触及或远远超出单台机器的某个上限的时候,我们惟有寻找别的机器的帮助或者继续升级的我们的硬件,但常见的方案还是横向扩展,通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长,我们的机器能不能通过线性增长就能满足需求?Sharding可以轻松的将计算,存储,I/O并行分发到多台机器上,这样可以充分利用多台机器各种处理能力,同时可以避免单点失败,提供系统的可用性,进行很好的错误隔离。

    综合以上因素,数据切分是很有必要的。 我们用免费的MySQL和廉价的Server甚至是PC做集群,达到小型机+大型商业DB的效果,减少大量的资金投入,降低运营成本,何乐而不为呢?所以,我们选择Sharding,拥抱Sharding。

    怎么做到数据切分

    数据切分可以是物理上的,对数据通过一系列的切分规则将数据分布到不同的DB服务器上,通过路由规则路由访问特定的数据库,这样一来每次访问面对的就不是单台服务器了,而是N台服务器,这样就可以降低单台机器的负载压力。

    数据切分也可以是数据库内的,对数据通过一系列的切分规则,将数据分布到一个数据库的不同表中,比如将article分为article_001,article_002等子表,若干个子表水平拼合有组成了逻辑上一个完整的article表,这样做的目的其实也是很简单的。举个例子说明,比如article表中现在有5000w条数据,此时我们需要在这个表中增加(insert)一条新的数据,insert完毕后,数据库会针对这张表重新建立索引,5000w行数据建立索引的系统开销还是不容忽视的。但是反过来,假如我们将这个表分成100 个table呢,从article_001一直到article_100,5000w行数据平均下来,每个子表里边就只有50万行数据,这时候我们向一张 只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降,极大了提高了DB的运行时效率,提高了DB的并发量。当然分表的好处还不知这些,还有诸如写操作的锁操作等,都会带来很多显然的好处。

    综上,分库降低了单点机器的负载;分表,提高了数据操作的效率,尤其是Write操作的效率。行文至此我们依然没有涉及到如何切分的问题。接下来,我们将对切分规则进行详尽的阐述和说明。

    上文中提到,要想做到数据的水平切分,在每一个表中都要有相冗余字符作为切分依据和标记字段,通常的应用中我们选用user_id作为区分字段,基于此就有如下三种分库的方式和规则:(当然还可以有其他的方式)

    (1) 号段分区

    user_id为1~1000的对应DB1,1001~2000的对应DB2,以此类推;

    优点:可部分迁移

    缺点:数据分布不均

    (2)hash取模分区

    对user_id进行hash(或者如果user_id是数值型的话直接使用user_id 的值也可),然后用一个特定的数字,比如应用中需要将一个数据库切分成4个数据库的话,我们就用4这个数字对user_id的hash值进行取模运算,也就是user_id%4,这样的话每次运算就有四种可能:结果为1的时候对应DB1;结果为2的时候对应DB2;结果为3的时候对应DB3;结果为0的时候对应DB4。这样一来就非常均匀的将数据分配到4个DB中。

    优点:数据分布均匀

    缺点:数据迁移的时候麻烦,不能按照机器性能分摊数据

    (3)在认证库中保存数据库配置

    就是建立一个DB,这个DB单独保存user_id到DB的映射关系,每次访问数据库的时候都要先查询一次这个数据库,以得到具体的DB信息,然后才能进行我们需要的查询操作。

    优点:灵活性强,一对一关系

    缺点:每次查询之前都要多一次查询,性能大打折扣

    以上就是通常的开发中我们选择的三种方式,有些复杂的项目中可能会混合使用这三种方式。 通过上面的描述,我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式,还需要我们不断的探索和发现。

    第3章 本课题研究的基本轮廓

    分布式数据方案提供功能如下:

    (1)提供分库规则和路由规则(RouteRule简称RR);

    (2)引入集群(Group)的概念,保证数据的高可用性;

    (3)引入负载均衡策略(LoadBalancePolicy简称LB);

    (4)引入集群节点可用性探测机制,对单点机器的可用性进行定时的侦测,以保证LB策略的正确实施,以确保系统的高度稳定性;

    (5)引入读/写分离,提高数据的查询速度;

    仅仅是分库分表的数据层设计也是不够完善的,当我们采用了数据库切分方案,也就是说有N台机器组成了一个完整的DB 。如果有一台机器宕机的话,也仅仅是一个DB的N分之一的数据不能访问而已,这是我们能接受的,起码比切分之前的情况好很多了,总不至于整个DB都不能访问。

    一般的应用中,这样的机器故障导致的数据无法访问是可以接受的,假设我们的系统是一个高并发的电子商务网站呢?单节点机器宕机带来的经济损失是非常严重的。也就是说,现在我们这样的方案还是存在问题的,容错性能是经不起考验的。当然了,问题总是有解决方案的。我们引入集群的概念,在此我称之为Group,也就是每一个分库的节点我们引入多台机器,每台机器保存的数据是一样的,一般情况下这多台机器分摊负载,当出现宕机情况,负载均衡器将分配负载给这台宕机的机器。这样一来,就解决了容错性的问题。

    如上图所示,整个数据层有Group1,Group2,Group3三个集群组成,这三个集群就是数据水平切分的结果,当然这三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master(当然Master也可以是多个)和 N个Slave,这些Master和Slave的数据是一致的。 比如Group1中的一个slave发生了宕机现象,那么还有两个slave是可以用的,这样的模型总是不会造成某部分数据不能访问的问题,除非整个 Group里的机器全部宕掉,但是考虑到这样的事情发生的概率非常小(除非是断电了,否则不易发生吧)。

    在没有引入集群以前,我们的一次查询的过程大致如下:请求数据层,并传递必要的分库区分字段 (通常情况下是user_id)。数据层根据区分字段Route到具体的DB,在这个确定的DB内进行数据操作。

    这是没有引入集群的情况,当时引入集群会 是什么样子的呢?我们的路由器上规则和策略其实只能路由到具体的Group,也就是只能路由到一个虚拟的Group,这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器,以进行具体的数据操作。

    基于这个环节的需求,我们引入了负载均衡器的概念 (LB),负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下:负载均衡器会分析当前sql的读写特性,如果是写操作或者是要求实时性很强的操作的话,直接将查询负载分到Master,如果是读操作则通过负载均衡策略分配一个Slave。

    我们的负载均衡器的主要研究方向也就是负载分发策略,通常情况下负载均衡包括随机负载均衡和加权负载均衡。随机负载均衡很好理解,就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的,它默认为每台机器的性能是一样的。假如真实的情况是这样的,这样做也是无可厚非的。假如实际情况并非如此呢?每个Slave的机器物理性能和配置不一样的情况,再使用随机的不考虑性能的负载均衡,是非常不科学的,这样一来会给机器性能差的机器带来不必要的高负载,甚至带来宕机的危险,同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从,我们引入了加权负载均衡,也就是在我们的系统内部通过一定的接口,可以给每台DB服务器分配一个权值,然后再运行时LB根据权值在集群中的比重,分配一定比例的负载给该DB服务器。当然这样的概念的引入,无疑增大了系统的复杂性和可维护性。有得必有失,我们也没有办法逃过的。

    有了分库,有了集群,有了负载均衡器,是不是就万事大吉了呢? 事情远没有我们想象的那么简单。虽然有了这些东西,基本上能保证我们的数据层可以承受很大的压力,但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了,那么系统的LB并不能得知,这样的话其实是很危险的,因为LB不知道,它还会以为slave2为可用状态,所以还是会给slave2分配负载。这样一来,问题就出来了,客户端很自然的就会发生数据操作失败的错误或者异常。

    这样是非常不友好的!怎样解决这样的问题呢? 我们引入集群节点的可用性探测机制 ,或者是可用性的数据推送机制。这两种机制有什么不同呢?首先说探测机制吧,顾名思义,探测即使,就是我的数据层客户端,不定时对集群中各个数据库进行可用性的尝试,实现原理就是尝试性链接,或者数据库端口的尝试性访问,都可以做到。

    那数据推送机制又是什么呢?其实这个就要放在现实的应用场景中来讨论这个问题了,一般情况下应用的DB 数据库宕机的话我相信DBA肯定是知道的,这个时候DBA手动的将数据库的当前状态通过程序的方式推送到客户端,也就是分布式数据层的应用端,这个时候在更新一个本地的DB状态的列表。并告知LB,这个数据库节点不能使用,请不要给它分配负载。一个是主动的监听机制,一个是被动的被告知的机制。两者各有所长。但是都可以达到同样的效果。这样一来刚才假设的问题就不会发生了,即使就是发生了,那么发生的概率也会降到最低。

    上面的文字中提到的Master和Slave ,我们并没有做太多深入的讲解。一个Group由1个Master和N个Slave组成。为什么这么做呢?其中Master负责写操作的负载,也就是说一切写的操作都在Master上进行,而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中,经过一些数据调查得出结论,读/写的比例大概在 10:1左右 ,也就是说大量的数据操作是集中在读的操作,这也就是为什么我们会有多个Slave的原因。

    但是为什么要分离读和写呢?熟悉DB的研发人员都知道,写操作涉及到锁的问题,不管是行锁还是表锁还是块锁,都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上,而读操作其其他 的N个节点上进行,从另一个方面有效的提高了读的效率,保证了系统的高可用性。

     转自:http://www.cnblogs.com/zhongxinWang/p/4262650.html

    【高并发解决方案】7、HAProxy安装和配置

    简介

    HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。

    HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。

    HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。

    HAProxy实现了一种事件驱动, 单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这

    些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

    安装

    复制代码
    #下载
    wget http://fossies.org/linux/misc/haproxy-1.6.9.tar.gz
    #解压
    tar -zxvf haproxy-1.6.9.tar.gz
    cd haproxy-1.6.9
    #安装
    make TARGET=linux2628 ARCH=x86_64 PREFIX=/usr/local/haproxy
    make install PREFIX=/usr/local/haproxy
    
    #参数说明
    TARGET=linux26 #内核版本,使用uname -r查看内核,如:2.6.18-371.el5,此时该参数就为linux26;kernel 大于2.6.28的用:TARGET=linux2628
    ARCH=x86_64 #系统位数
    PREFIX=/usr/local/haprpxy #/usr/local/haprpxy为haprpxy安装路径
    复制代码

    配置

    复制代码
    ###########全局配置#########
    global
      log 127.0.0.1 local0 #[日志输出配置,所有日志都记录在本机,通过local0输出]
      log 127.0.0.1 local1 notice #定义haproxy 日志级别[error warringinfo debug]
      daemon #以后台形式运行harpoxy
      nbproc 1 #设置进程数量
      maxconn 4096 #默认最大连接数,需考虑ulimit-n限制
      #user haproxy #运行haproxy的用户
      #group haproxy #运行haproxy的用户所在的组
      #pidfile /var/run/haproxy.pid #haproxy 进程PID文件
      #ulimit-n 819200 #ulimit 的数量限制
      #chroot /usr/share/haproxy #chroot运行路径
      #debug #haproxy 调试级别,建议只在开启单进程的时候调试
      #quiet
    
    ########默认配置############
    defaults
      log global
      mode http #默认的模式mode { tcp|http|health },tcp是4层,http是7层,health只会返回OK
      option httplog #日志类别,采用httplog
      option dontlognull #不记录健康检查日志信息
      retries 2 #两次连接失败就认为是服务器不可用,也可以通过后面设置
      #option forwardfor #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip
      option httpclose #每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现
      #option redispatch #当serverId对应的服务器挂掉后,强制定向到其他健康的服务器,以后将不支持
      option abortonclose #当服务器负载很高的时候,自动结束掉当前队列处理比较久的链接
      maxconn 4096 #默认的最大连接数
      timeout connect 5000ms #连接超时
      timeout client 30000ms #客户端超时
      timeout server 30000ms #服务器超时
      #timeout check 2000 #心跳检测超时
      #timeout http-keep-alive10s #默认持久连接超时时间
      #timeout http-request 10s #默认http请求超时时间
      #timeout queue 1m #默认队列超时时间
      balance roundrobin #设置默认负载均衡方式,轮询方式
      #balance source #设置默认负载均衡方式,类似于nginx的ip_hash
      #balnace leastconn #设置默认负载均衡方式,最小连接数
    
    ########统计页面配置########
    listen stats
      bind 0.0.0.0:1080 #设置Frontend和Backend的组合体,监控组的名称,按需要自定义名称
      mode http #http的7层模式
      option httplog #采用http日志格式
      #log 127.0.0.1 local0 err #错误日志记录
      maxconn 10 #默认的最大连接数
      stats refresh 30s #统计页面自动刷新时间
      stats uri /stats #统计页面url
      stats realm XingCloud\ Haproxy #统计页面密码框上提示文本
      stats auth admin:admin #设置监控页面的用户和密码:admin,可以设置多个用户名
      stats auth Frank:Frank #设置监控页面的用户和密码:Frank
      stats hide-version #隐藏统计页面上HAProxy的版本信息
      stats admin if TRUE #设置手工启动/禁用,后端服务器(haproxy-1.4.9以后版本)
    
    ########设置haproxy 错误页面#####
    #errorfile 403 /home/haproxy/haproxy/errorfiles/403.http
    #errorfile 500 /home/haproxy/haproxy/errorfiles/500.http
    #errorfile 502 /home/haproxy/haproxy/errorfiles/502.http
    #errorfile 503 /home/haproxy/haproxy/errorfiles/503.http
    #errorfile 504 /home/haproxy/haproxy/errorfiles/504.http
    
    ########frontend前端配置##############
    frontend main
      bind *:80 #这里建议使用bind *:80的方式,要不然做集群高可用的时候有问题,vip切换到其他机器就不能访问了。
      acl web hdr(host) -i www.abc.com  #acl后面是规则名称,-i为忽略大小写,后面跟的是要访问的域名,如果访问www.abc.com这个域名,就触发web规则,。
      acl img hdr(host) -i img.abc.com  #如果访问img.abc.com这个域名,就触发img规则。
      use_backend webserver if web   #如果上面定义的web规则被触发,即访问www.abc.com,就将请求分发到webserver这个作用域。
      use_backend imgserver if img   #如果上面定义的img规则被触发,即访问img.abc.com,就将请求分发到imgserver这个作用域。
      default_backend dynamic #不满足则响应backend的默认页面
    
    ########backend后端配置##############
    backend webserver #webserver作用域
      mode http
      balance roundrobin #balance roundrobin 负载轮询,balance source 保存session值,支持static-rr,leastconn,first,uri等参数
      option httpchk /index.html HTTP/1.0 #健康检查, 检测文件,如果分发到后台index.html访问不到就不再分发给它
      server web1 10.16.0.9:8085 cookie 1 weight 5 check inter 2000 rise 2 fall 3
      server web2 10.16.0.10:8085 cookie 2 weight 3 check inter 2000 rise 2 fall 3
      #cookie 1表示serverid为1,check inter 1500 是检测心跳频率 
      #rise 2是2次正确认为服务器可用,fall 3是3次失败认为服务器不可用,weight代表权重
    
    backend imgserver
      mode http
      option httpchk /index.php
      balance roundrobin 
      server img01 192.168.137.101:80 check inter 2000 fall 3
      server img02 192.168.137.102:80 check inter 2000 fall 3
    
    backend dynamic 
      balance roundrobin 
      server test1 192.168.1.23:80 check maxconn 2000 
      server test2 192.168.1.24:80 check maxconn 2000
    
    
    listen tcptest 
      bind 0.0.0.0:5222 
      mode tcp 
      option tcplog #采用tcp日志格式 
      balance source 
      #log 127.0.0.1 local0 debug 
      server s1 192.168.100.204:7222 weight 1 
      server s2 192.168.100.208:7222 weight 1
    复制代码

    负载均衡算法

    复制代码
    一、roundrobin,表示简单的轮询,每个服务器根据权重轮流使用,在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。
    
    二、static-rr,表示根据权重,建议关注;每个服务器根据权重轮流使用,类似roundrobin,但它是静态的,意味着运行时修改权限是无效的。另外,它对服务器的数量没有限制。
    
    三、leastconn,表示最少连接者先处理,建议关注;leastconn建议用于长会话服务,例如LDAP、SQL、TSE等,而不适合短会话协议。如HTTP.该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。
    
    四、source,表示根据请求源IP,建议关注;对请求源IP地址进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。
               只要服务器正常,同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化,那么客户端会定向到不同的服务器;
               该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连;
               该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
    五、uri,表示根据请求的URI;表示根据请求的URI左端(问号之前)进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。
            只要服务器正常,同一个URI地址总是访问同一个服务器。
            一般用于代理缓存和反病毒代理,以最大限度的提高缓存的命中率。该算法只能用于HTTP后端;
            该算法一般用于后端是缓存服务器;
            该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
    六、url_param,表示根据请求的URl参数'balance url_param' requires an URL parameter name
                  在HTTP GET请求的查询串中查找<param>中指定的URL参数,基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求;
                  该算法一般用于将同一个用户的信息发送到同一个后端服务器;
                  该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
    七、hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求;
                  在每个HTTP请求中查找HTTP头<name>,HTTP头<name>将被看作在每个HTTP请求,并针对特定的节点;
                  如果缺少头或者头没有任何值,则用roundrobin代替;
                  该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
    八、rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求。
                         为每个进来的TCP请求查询并哈希RDP cookie<name>;
                         该机制用于退化的持久模式,可以使同一个用户或者同一个会话ID总是发送给同一台服务器。
                         如果没有cookie,则使用roundrobin算法代替;
                         该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
    
    #其实这些算法各有各的用法,我们平时应用得比较多的应该是roundrobin、source和lestconn。
    
    haproxy负载均衡算法
    复制代码

    ACL规则定义

    复制代码
    ########ACL策略定义#########################
    1、#如果请求的域名满足正则表达式返回true -i是忽略大小写
    acl denali_policy hdr_reg(host) -i ^(www.inbank.com|image.inbank.com)$
    
    2、#如果请求域名满足www.inbank.com 返回 true -i是忽略大小写
    acl tm_policy hdr_dom(host) -i www.inbank.com
    
    3、#在请求url中包含sip_apiname=,则此控制策略返回true,否则为false
    acl invalid_req url_sub -i sip_apiname=#定义一个名为invalid_req的策略
    
    4、#在请求url中存在timetask作为部分地址路径,则此控制策略返回true,否则返回false
    acl timetask_req url_dir -i timetask
    
    5、#当请求的header中Content-length等于0时返回 true
    acl missing_cl hdr_cnt(Content-length) eq 0
    
    #########acl策略匹配相应###################
    1、#当请求中header中Content-length等于0 阻止请求返回403
    block if missing_cl
    
    2、#block表示阻止请求,返回403错误,当前表示如果不满足策略invalid_req,或者满足策略timetask_req,则阻止请求。
    block if !invalid_req || timetask_req
    
    3、#当满足denali_policy的策略时使用denali_server的backend
    use_backend denali_server if denali_policy
    
    4、#当满足tm_policy的策略时使用tm_server的backend
    use_backend tm_server if tm_policy
    
    5、#reqisetbe关键字定义,根据定义的关键字选择backend
    reqisetbe ^Host:\ img dynamic
    reqisetbe ^[^\ ]*\ /(img|css)/ dynamic
    reqisetbe ^[^\ ]*\ /admin/stats stats
    
    6、#以上都不满足的时候使用默认mms_server的backend
    default_backend mms
    
    haproxy acl定义
    复制代码

    配置日志

    复制代码
        1.创建记录日志文件
            mkdir /var/log/haproxy
            chmod a+w /var/log/haproxy
        2.编辑/etc/rsyslog.conf
          a) 开启514 UDP监听
               # Provides UDP syslog reception
               $ModLoad imudp
               $UDPServerRun 514
          b) 指定日志存放地点:
              local0.*      /var/log/haproxy/haproxy.log
        3.haproxy.conf 配置:
           global
             # 配置local2事件
            log    127.0.0.1  local0 info
    
        4.重启 rsyslog服务
           systemctl  restart   rsyslog
    复制代码

    启动

    /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.cfg 

    查看状态

    复制代码
    http://192.168.1.22:1080/stats
    
    #说明:
    #1080即haproxy配置文件中监听端口
    s#tats 即haproxy配置文件中的监听名称

    监控页面详细说明

    复制代码

    展开全文
  • 本文档详细的描述了当前IT行业人士写软件解决方案存在的一些问题,并指出了如何写好一个软件解决方案的策略和方法,希望能够帮助大家!
  • 软件行业一般的产品都会有解决方案,但每个公司的解决方案都是各有自己的风格和特色。有些所谓的解决方案在个人看来可能称不上是一种解决方案,即没有解决什么问题,也满足不了一个方案的基本要求。本文就对普通的中...
  • 首先,在Visual Studio中,一个解决方案是可以包含一个或多个项目的。 若对整个解决方案: 1.在“解决方案资源管理器”,选择或打开解决方案。 2.在菜单栏上,依次选择“生成”,然后选择以下命令之一: a、选择...
  • 前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层...解决方案
  •  项目进行过程中,每次更新代码之后会去点击“生成解决方案”或者“重新生成解决方案”,也疑虑过这两个选项之间的细微差别,通过上网查询,做如下简单总结。 【概念理解】  重新生成:  重新生成解决方案...
  • 错误代码“err_connection_timed_out”的解决方案问题描述解决方案1:清除浏览器历史记录和缓存(亲测有效)解决方案2:修改Windows主机File解决方案3:刷新或更新DNS和IP地址 (亲测有效)解决方案4:过滤防火墙和...
  • 一般而言,编写项目解决方案,首先应该搭建解决方案的框架结构,然后运用个人的项目经验和总结能力逐一编写出符合项目期望的解决方案。 IT行业项目解决方案,通常会包括方案概述、项目需求与问题分析、项目解决方案...
  • 生成解决方案与重新生成解决方案 生成解决方案:在一个项目中,当对文件进行编译的时候,使用生成解决方案会尝试优化整个过程,根据修改的日期,编译修改过的文件 重新生成解决方案:首先删除一些中间文件,然后...
  • 解决方案平台一般有64位,32位,以及Any CPU,Mixed Platforms 解决方案配置一般有Debug和Release两个版本 编译出来的不同版本库是存在兼容性问题的,32位操作系统肯定是不能运行64位可执行程序的,在编译和安装库的...
  • Win10 磁盘占用100%(卡顿)的解决方案本文提供一种Win10系统磁盘占用100%(卡顿)问题的解决方案(亲测可行)参考配置 电脑:Thinkpad T460p(机械硬盘) 系统:Win10 家庭中文版 (版本号1709) 基本假设 电脑没有...
  • 解决方案销售读书笔记1、前言2、解决方案销售的概念2.1、 解决方案什么是解决方案销售常见销售难题常见销售管理难题常见高层管理难题2.2、原则解决方案销售原则2.3、销售流程销售流程要素两种销售流程模型步骤流程...
  • VS解决方案和各个项目文件夹以及解决方案和各个项目对应的配置文件包含关系,假设新建一个项目ssyy,解决方案起名fangan,注意解决方案包括项目,此时生成的最外层目录为fangan代表整个解决方案的内容都在这个文件夹...
  • 打开VS2019,选择创建新项目。 在搜索框搜索解决方案,或者鼠标滚动...即空白解决方案创建好了。 一个解决方案下面可以有多个项目。 原文发布于我本人另一个CSDN账号,现在那个已经不用了,只用这个,并非抄袭。 ...
1 2 3 4 5 ... 20
收藏数 2,195,348
精华内容 878,139
关键字:

解决方案