为什么要扩容呢？也就是说，不管你怎么优化性能，能达到的最大值是一定的。对于用户量大的应用，可以对服务器进行各种优化，比如限流，资源隔离，但是上限还是有的。这个时候我们就应该换一下我们的硬件，比如换个更强的CPU，更大的内存。在上一篇文章中，举了一个在学生食堂吃饭的例子。如果学生比较多，可以使用令牌桶算法优先给有令牌的高中生，但是如果高中生还是很多怎么办？唯一的办法就是增加窗口或食堂的数量，即硬件扩容。扩容策略扩容策略可以分为两种，一种是对单机的整体容量进行扩容，即机器包含CPU、内存、存储设备等，另一种是对相应的部件进行扩容，比如扩内存，扩磁盘，扩CPU。整机硬件扩展的优势在于有很多专业的服务器硬件供应商，如IBM、浪潮、DELL、HP等，专业的硬件供应商可能在组装和匹配方面有更多的经验，有些公司会将组件优化到让服务器更稳定。这可以比作购买一台电脑。有的人可能会选择购买淘宝卖家组装好的台式机，有的人可能会购买各种硬件自己在家组装。对于普通人来说，选择前者是比较靠谱的选择，因为即使了解了一些硬件参数，也很难保证自己搭配的机器能否发挥出各个部件的最大性能。元器件对于一些技术能力强的公司，更多的是购买各种元器件，自己组装，这样比较便宜，因为可以节省组装成本，而且可以根据业务进行定制。例如，一些公司是计算密集型的。然后主要是更换更强的CPU，一些IO密集型的，那么内存要扩容，有的公司需要存储大量的数据，所以可能扩容硬盘等存储设备。组件包括：cpuIntel、AMD、参考频率、线程数等网卡100M->千兆->10G内存ECC校验盘SCSIHDD（机械）、HHD（混合）、SATASSD、PCI-eSSD、MVMeSSDAKF拆分原则对于一个应用，如果单机不足以支撑服务请求，那么可以建立master-master、master-slave等模式的集群：这叫做AKF原则X轴扩展，目的是在多台机器上分发请求，但是多台机器之间需要解决数据同步的问题。机器越多，数据越有可能不同步，也就意味着无法实现无限的整体复制和扩容。因此，我们可以在服务器中整理收集热点业务请求，将业务分离，只对热点业务进行扩展。这就是AKF原理的Y轴拆分：业务拆分后，某个业务可能过热，即Y轴拆分后，如果水平复制仍然不足以支持数据请求，那么业务数据可以分裂。具体来说，某个业务的数据可以放在多个地方，比如在湖北、北京、上海部署机房，当来自世界各地的人需要请求数据时，服务由就近的服务器提供。拆分扩容后的问题随着业务的增长，系统越来越庞大，按照系统功能拆分成独立的、互通的项目，如交易系统、财务系统、生产流程系统、物流系统、网站系统等等等，但是分布式结构有很多问题。这其中的每一个问题都值得深入探讨，所以我在这里简单提一下，后面再开篇。数据共享问题所有服务之间如何共享和同步数据是一个需要考虑的问题。在微服务架构中，不可能只有一份数据，也无法避免因机器损坏等原因导致的数据丢失。多份数据之间如何同步？目前可供参考的方案是建立数据中心，搭建数据库集群。接口调用问题不同服务器之间的调用遵循远程调用协议RPCJAVARMI：Java远程方法调用，即JavaRMI（JavaRemoteMethodInvocation）是Java编程语言中实现远程过程调用的应用程序编程接口。它使在客户端上运行的程序能够调用远程服务器上的对象。dubbo：提供面向高性能RPC接口代理调用持久化数据雪崩问题数据库分库分表资源隔离缓存设置数据持久化策略高并发问题缓存：如缓存击穿、穿透、雪崩等数据闭环：forIt很容易理解。比如淘宝，有web版，IOS版，Android版，还有什么是淘宝等等，虽然客户端不一样，但是显示的商品信息都是一样的，就是一个商品，不管是哪端用的同样的数据，需要一个解决方案来解决基于同一个数据并发在不同端显示不同的问题，这就是数据闭环。数据一致性问题这是一个难点。总体思路是如何保证多台服务器之间的数据一致性。同一种产品在不同的客户端和服务器上的价格应该是一样的。通常使用分布式锁。数据库扩展：集群先简单说一下分布式和集群的区别。这两个词经常一起出现，但含义不同。分布式会缩短单个任务的执行时间来提高工作效率，而集群则强调通过增加单位时间内执行的操作数来提高效率。分布式简单点说就是在每台电脑上划分步骤，不考虑依赖关系，而集群方案就是同时处理几个任务。当单一的数据库存储难以满足业务需求时，采用集群的方式将数据存储在不同的服务器上，可以是master-master也可以是master-slave，master-slave负责写，slave负责读，与数据库相关的压力被分解到多台机器上。分布式ID在复杂的分布式系统中，往往需要对大量的数据和消息进行唯一标识。很容易想到使用自增，但是自增存在很多问题，比如ID规则太强，可能被恶意查询收集。面对越来越多的数据，数据分库分表后需要一个唯一的ID。标识一条数据或者一条消息，那么数据库的自增ID显然不能满足需求；特别是产品、订单、用户也需要唯一的ID来进行标识。这时候，一个能够生成全球唯一ID的系统就非常有必要了。综上所述，业务系统对身份证号的要求是什么？分布式ID要求面对分布式ID，需要满足以下要求：全局唯一性：不能出现重复的ID号。既然是唯一标识，这是最基本的要求。增加趋势：聚簇索引用于MySQLInnoDB引擎。由于大多数RDBMS使用B-tree数据结构来存储索引数据，因此我们在选择主键时应尽量使用有序的主键来保证写入性能。单调递增：保证下一个ID必须大于上一个ID，比如交易版本号、IM增量消息、排序等特殊需求。信息安全：如果ID是连续的，很容易被恶意用户窃取作品，直接按顺序下载指定的URL即可；如果是订单号，那就更危险了，竞争对手可以直接知道我们每天的订单量。因此，在一些应用场景中，需要ID是不规则的，不规则的。上面的123对应三种不同的场景，但是3和4的要求是互斥的，即不能用同一个方案来满足。除了对身份证号本身的要求外，业务对身份证号生成系统的可用性也有极高的要求。想象一下，如果ID生成系统瘫痪，所有与数据相关的动作都无法执行，那将带来灾难。由此可以得出，下一代ID生成系统至少应该做到以下几点：平均延迟和TP999延迟要尽可能低；availability是5个9（这是美团的要求，阿里等一些公司要求6个9）；高QPS。分布式ID生成策略目前业界常用的ID生成策略有很多，比如UUID、Snowflake生成算法、Redis、Zookeeper等，这里只简单说一下UUID和Snowflake，后面会详细讨论.UUID生成算法UUID（UniversallyUniqueIdentifier）标准格式包含32个16进制数，用连字符分成5段，36个字符，形式为8-4-4-4-12，例子：550e8400-e29b-41d4-a716-446655440000，目前业界有5种生成UUID的方法。优点：非常高性能：本地生成，无网络消耗。缺点：不易存储：UUID太长，16字节128位，通常用36长度的字符串表示，很多场景不适用。信息不安全：基于MAC地址生成UUID的算法可能会导致MAC地址泄露。该漏洞曾被用于寻找Melissa病毒的创建者。使用ID作为主键时，在特定环境下会出现一些问题。比如在DB主键的场景下，UUID就很不适用：①MySQL官方建议主键越短越好[4]，36个字符的UUID长度不符合要求。除聚簇索引外的所有索引都称为二级索引。在InnoDB中，二级索引中的每条记录都包含该行的主键列，以及为二级索引指定的列。InnoDB使用这个主键值来搜索聚集索引中的行。主键长，二级索引占用空间大，主键短有优势。data可能会导致数据位置频繁变化，严重影响性能。雪花生成算法该方案大致是一种通过划分命名空间生成ID的算法（UUID也算在内，因为比较常用，所以单独分析）。该方案将64位分为多个段，分别来标记机器、时间等，例如snowflake中的64位分别表示如下图（图片来自网络）：41位时间可以表示(1L<<41)/(1000L360024*365)=69年，10位机器分别可以表示1024台机器。如果我们有IDC划分的需求，我们也可以将10bit划分为IDC划分为5bit，工作机划分为5bit。这样就可以表示32个IDC，每个IDC可以有32台机器，可以根据自己的需要来定义。12个自增序号可以代表212212个ID。理论上，雪花方案的QPS约为409.6w/s。这种分发方式可以保证任何一个IDC的任何一台机器在任何毫秒内生成的ID都是不同的。的。这种方式的优缺点是：优点：毫秒数在高位，自增序列在低位，整个ID呈递增趋势。不依赖数据库等第三方系统，以服务形式部署，稳定性更高，生成ID的性能更高。比特可以根据自己的业务特点进行分配，非常灵活。缺点：对机器时钟依赖性强，如果拨回机器上的时钟，会造成重复编号或服务不可用。换句话说，弹性扩容就是让集群在一定时间内按照计划自动扩充资源，当恢复设定的计划时释放资源。这样可以解决资源的规律性峰谷需求，达到充分合理利用资源的目的。但是，弹性扩展存在一些问题：首先，虚拟机的弹性能力较弱。使用虚拟机部署业务，在弹性扩容时，需要经历申请虚拟机、创建并部署虚拟机、配置业务环境、启动业务实例等步骤。前几步属于私有云平台，后面几步属于业务工程师。一次扩容需要多部门协作，扩容时间以小时计，自动化难度大。如果能够实现自动化的“一键式快速扩容”，将大大提高业务的灵活性和效率，释放更多的人力，消除人工操作带来的事故隐患。其次，IT成本高。由于虚拟机弹性弱，业务部门普遍采用预留大量机器和服务实例的做法，以应对流量高峰和突发流量。即先部署大量虚拟机或物理机，根据业务高峰期所需资源进行资源预留，一般是非高峰期资源需求的两倍。资源预留的方式带来了非常高的IT成本。在非高峰时段，这些机器资源闲置，也是一种巨大的浪费。作者：迫不及待口琴\链接：www.cnblogs.com/Courage129/p/14425669.html近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.世界之最！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
