随着业务的发展，对服务器基础设施的需求也会随之增长。企业需要考虑服务器成本与其业务规模之间的关系，以优化成本并确保其基础设施满足业务需求。
服务器成本的影响因素
影响服务器成本的因素包括：
- 服务器类型：不同类型的服务器具有不同的成本，例如虚拟服务器、专用服务器和云服务器。
- 服务器规格：服务器的处理能力、内存、存储空间和网络连接等规格会影响成本。
- 服务器数量：随着业务需求的增长，企业可能需要添加更多服务器。
- 服务器管理：管理服务器的成本，包括软件许可证、支持和维护。
业务规模对服务器成本的影响
业务规模对服务器成本的影响可以概括为以下关系：
- 业务增长：业务增长会导致对服务器资源的需求增加，从而增加服务器成本。
- 数据量：存储和处理大量数据的企业需要更多或更高级别的服务器来满足其存储和计算需求。
- 用户数量：用户数量的增加会导致服务器负载的增加，需要更强大的服务器或更多服务器。
- 应用程序复杂性：运行复杂应用程序的企业需要具有更高处理能力和内存的服务器。
如何随着业务增长调整服务器成本
企业可以采取以下措施来随着业务增长调整服务器成本：
- 优化服务器利用率：通过监控服务器负载并实施适当的自动化工具来优化服务器利用率，可以提高服务器的效率，并减少添加新服务器的需求。
- 选择合适的服务器类型：根据业务需求选择合适的服务器类型，例如云服务器的可扩展性和成本效益，可以降低服务器成本。
- 进行容量规划：制定容量规划策略，以预测服务器需求并提前计划升级或扩展，可以避免因意外需求高峰而增加成本。
- 外包服务器管理：将服务器管理外包给专业服务提供商可以降低内部管理成本，并提供更高的专业知识。
结论
服务器成本是随着业务增长而需要考虑的重要因素。通过了解服务器成本的影响因素，以及业务规模对服务器成本的影响，企业可以制定策略来优化成本并确保其服务器基础设施满足其业务需求。通过优化服务器利用率、选择合适的服务器类型、进行容量规划和外包服务器管理，企业可以控制服务器成本，并实现业务平稳增长。
BS和CS结构有什么区别？
相关概念：C/S结构，即Client/Server(客户机/服务器)结构，是大家熟知的软件系统体系结构，通过将任务合理分配到Client端和Server端，降低了系统的通讯开销，可以充分利用两端硬件环境的优势。
早期的软件系统多以此作为首选设计标准。
B/S结构，即Browser/Server(浏览器/服务器)结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。
在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓3-tier结构。
B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。
随着Windows 98/Windows 2000将浏览器技术植入操作系统内部，这种结构更成为当今应用软件的首选体系结构。
C/S 与 B/S 区别： Client/Server是建立在局域网的基础上的/Server是建立在广域网的基础上的,但并不是说B/S结构不能在局域网上使用,如智赢IPOWER,在单机,局限网,广域网均能使用。
1．硬件环境不同: C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务. B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备. 信息自己管理. 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行 2．对安全要求不同 C/S 对服务端、客户端都安全都要考虑。
B/S 因没有客户端，所以只注重服务端安全即可。
3．对程序架构不同 C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑. B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟. 例如智赢IPOWER，采用AJAX和数据存储优化技术，相比一般B/S架构软件速度提高30%至99%。
4．软件重用不同 C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好. B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子 5．系统维护不同 系统维护是软件生存周期中,开销大, ——-重要 C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统 B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级. 6．处理问题不同 C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统 B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小. 7．用户接口不同 C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高 B/S 建立在浏览器上, 通过WEB服务或其他公共可识别描述语言可跨平台，使用更灵活。
不仅可应用在Window平台上，还可应用于unix/Linux等平台。
8．信息流不同 C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低 B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心。
B/S模式的优点和缺点B/S结构的优点（1）、具有分布性特点，可以随时随地进行查询、浏览等业务处理。
（2）、业务扩展简单方便，通过增加页面即可增加服务器功能。
（3）、维护简单方便，只需要改变网面，即可实现所有用户的同步更新。
（4）、共享性强B/S 模式的缺点（1）、响应速度不及C/S，随着AJAX技术的发展，相比传统B/S结构软件提升一倍速度。
（2）、用户体验效果不是很理想，B/S需要单独界面设计，厂商之间的界面也是千差万别，由于浏览器刷新机制，使用时有刷屏现象，好在AJAX技术解决这一难题，像用友，智赢等开发的B/S架构软件用户体验效果与C/S差不多。
C/S 模式的优点和缺点 C/S 模式的优点 1.由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度较快。
3.C/S结构的管理信息系统具有较强的事务处理能力。
C/S 模式的缺点 1.只适用于局域网。
而随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。
这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。
2.客户端需要安装专用的客户端软件。
首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。
特别是有很多分部或专卖店的情况，不是工作量的问题，而是路程的问题。
还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。
3.对客户端的操作系统一般也会有限制。
可能适应于Win98, 但不能用于win2000或Windows XP。
或者不适用于微软新的操作系统等等，更不用说Linux、Unix等。
B/S架构软件的优势与劣势（1）、维护和升级方式简单。
目前，软件系统的改进和升级越来越频繁，C/S系统的各部分模块中有一部分改变，就要关联到其它模块的变动，使系统升级成本比较大。
B/S与C/S处理模式相比，则大大简化了客户端，只要客户端机器能上网就可以。
对于B/S而言，开发、维护等几乎所有工作也都集中在服务器端，当企业对网络应用进行升级时，只需更新服务器端的软件就可以，这减轻了异地用户系统维护与升级的成本。
如果客户端的软件系统升级比较频繁，那么B/S架构的产品优势明显——所有的 升级操作只需要针对服务器进行。
（2）、系统的性能 在系统的性能方面，B/S占有优势的是任何时间、任何地点、任何系统，只要可以使用浏览器上网，就可以使用B/S系统的终端。
采用C/S结构时，客户端和服务器端都能够处理任务，这虽然对客户机的要求较高，但因此可以减轻服务器的压力。
（3）、系统的开发 C/S结构是建立在中间件产品基础之上的，要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。
这对应用开发者提出了较高的要求，而且迫使应用开发者投入很多精力来解决应用程序以外的问题。
这使得应用程序的维护、移植和互操作变得复杂。
如果客户端是在不同的操作系统上，C/S结构的软件需要开发不同版本的客户端软件。
B/S、C/S结构软件商业运用上的比较管理软件是为企业服务的，企业选用管理软件不仅要从技术上考虑，还要从商业运用方面来考虑，下文将从商业运用的角度对两种结构的软件进行比较。
1，投入成本比较。
B/S结构软件一般只有初期一次性投入成本。
对于集团来讲，有利于软件项目控制和避免IT黑洞，而C/S结构的软件则不同，随着应用范围的扩大，投资会连绵不绝。
2，硬件投资保护比较。
在对已有硬件投资的保护方面，两种结构也是完全不同的。
当应用范围扩大，系统负载上升时，C/S结构软件的一般解决方案是购买更高级的中央服务器，原服务器放弃不用，这是由于C/S软件的两层结构造成的，这类软件的服务器程序必须部署在一台计算机上；而B/S结构（如智赢CRM管理系列）则不同，随着服务器负载的增加，可以平滑地增加服务器的个数并建立集群服务器系统，然后在各个服务器之间做负载均衡。
有效地保护了原有硬件投资。
3，企业快速扩张支持上的比较。
对于成长中的企业，快速扩张是它的显著特点。
例如迪信通公司，每年都有新的配送中心成立，每月都有新的门店开张。
应用软件的快速部署，是企业快速扩张的必要保障。
对于C/S结构的软件来讲，由于必须同时安装服务器和客户端、建设机房、招聘专业管理人员等，所以无法适应企业快速扩张的特点。
而B/S结构软件，只需一次安装，以后只需设立账号、培训即可。
其次，随着软件应用的扩张，对系统维护人才的需求有可能成为企业快速扩张的制约瓶颈。
如果企业开店上百家，对计算机专业人才的需求就将是企业面临的巨大挑战之一。
抛开人力成本不说，一个企业要招到这么多的专业人才并且留住他们也是不可能的。
所以，采用C/S结构软件必然会制约企业未来的发展。
另外，大多数C/S结构的软件都是通过ODBC直接连到数据库的，安全性差不说，其用户数也是受限的。
每个连到数据库的用户都会保持一个ODBC连接，都会一直占用中央服务器的资源，对中央服务器的要求非常高，使得用户扩充受到极大的限制。
而B/S结构软件则不同，所有的用户都是通过一个JDBC连接缓冲池连接到数据库的，用户并不保持对数据库的连接，用户数基本上是无限的。
从以上的分析可以看出，B/S结构的管理软件和C/S结构软件各有各的的优势。
而从国外的发展趋势来看。
目前，国外大型企业管理软件要么已经是B/S结构的，要么正在经历从C/S到B/S结构的转变。
从国内诸多软件厂商积极投入开发B/S结构软件的趋势来看，B/S结构的大型管理软件可能在将来的几年内占据管理软件领域的主导地位。
服务器和云服务器的区别
1、资源弹性调配不同
云服务器是支持资源的弹性调配的，这意味着我们自由地增加或缩减CPU、内存、磁盘、带宽等资源，但我们还应该知道，这种弹性伸缩，不止单台云服务器中的纵向伸缩，还包括增加/缩减虚拟机数量的横向伸缩。
普通服务器资源受限于单台服务器配置，如需资源扩容，则需要技术人员在实体服务器硬件中增加磁盘或内存条等，这个过程耗费的时间成本难以支撑企业应用需求的灵活变化。
2、节点规模不同
云服务器的计算资源是从大量经过整合虚拟化的物理服务器中调度获取的，从节点规模看，这样的虚拟化规模可能是几台、数十台、数百台物理服务器，也可能是跨数据中心的成千上万台实体硬件构建起大型云端虚拟资源池。
普通服务器的节点规模则受限于机柜、机房等硬件环境以及虚拟化的程度。
3、分布式存储不同
云服务器采用的是分布式存储，例如知了云采用的ceph分布式存储系统，以良好的可扩展性、高性能以及高可靠性为显著特征。
可实现实时多重副本容灾，无单点故障，可有效规避多种故障，并且支持存储资源的弹性伸缩， 并使云服务器具备热迁移等功能。
普通服务器则无法实现分布式存储，一旦发生硬件故障，数据安全将面临严重的丢失、损毁甚至无法找回等风险，因此企业通常会部署RAID10阵列安全策略，但这需要面临高额的硬件购置等费用和成本，增加公司财政负担。
4、概念不同
云端服务器是出自WEB3.0里的概念，具有高度分布式、高度虚拟化等特点，常见的青牛商机智能营销云终端是全球首款基于桌面的轻量级通讯及信息化管理营销平台。
普通服务器，也称伺服器，是提供计算服务的设备。
由于服务器需要响应服务请求，并进行处理，因此一般来说服务器应具备承担服务并且保障服务的能力。
服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
在网络环境下，根据服务器提供的服务类型不同，分为文件服务器、数据库服务器、应用程序服务器、WEB服务器等。
扩展资料：
云服务器可以有效的解决传统物理租机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。在实际应用中的云主机具有三个方面的弹性能力：
1、云服务器服务配置与业务规模可根据用户的需要进行配置，并可灵活的进行调整；
2、用户申请的云服务器服务可以实现快速供应和部署，实现了集群内弹性可伸缩；
3、计费方式灵活，用户无需支付押金，且有多种支付方式供用户选择。
网络百科-云端服务器
网络百科-普通服务器
数据库架构选型与落地，看这篇就够了
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。
因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。
以下，我从数据库架构、选型与落地来让大家入门。
数据库会面临什么样的挑战呢？
业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。
为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。
将数据库的写操作和读操作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。
这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读操作的场景。
因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；
优点：
缺点：
在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。
优点：
缺点：
在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。
这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。
但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈（单个服务器的IO有上限）。
所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。
优点：
缺点：
四、分库分表
在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。
所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。
分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。
优点：
缺点：
注：分库还是分表核心关键是有没有IO瓶颈 。
分片方式都有什么呢？
RANGE（范围分片）
将业务表中的某个 关键字段排序 后，按照顺序从0到一个表，到一个表。
最常见的就是 按照时间切分 （月表、年表）。
比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。
优点：
缺点：
HASH（哈希分片）
将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。
优点：
缺点：
讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。
那么，我们应该如何选择数据库架构呢？
虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。
混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。
1、对事务支持
分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。
2、多库结果集合并 （group by，order by）
由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等操作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。
3、数据延迟
主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。
4、跨库join
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。
5、分片扩容
水平分片之后，一旦需要做扩容时。
需要将对应的数据做一次迁移，成本代价都极高的。
6、ID生成
分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。
一、应用层依赖类（JDBC）
这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。
此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等操作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。
中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。
优点
缺点
二、中间层代理类（Proxy）
这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。
所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。
在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是Http协议请求。
比较有代表性的产品有开创性质的Amoeba、阿里开源的Cobar、社区发展比较好的 Mycat （基于Cobar开发）等。
优点
缺点
JDBC方案 ：无中心化架构，兼容市面上大多数关系型数据库，适用于开发高性能的轻量级 OLTP 应用（面向前台）。
Proxy方案 ：提供静态入口以及异构语言的支持，适用于 OLAP 应用（面向后台）以及对分片数据库进行管理和运维的场景。
混合方案 ：在大型复杂系统中存在面向C端用户的前台应用，也有面向企业分析的后台应用，这个时候就可以采用混合模式。
JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （计划中）这3款相互独立的产品组成，他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位为透明化的 数据库代理端 ，提供封装了 数据库二进制协议的服务端版本 ，用于完成对 异构语言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加友好。
向 应用程序完全透明 ，可直接当做MySQL使用。
适用于任何兼容MySQL协议的客户端。
Sharding-JDBC
定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。
它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为 增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 。
以电商SaaS系统为例，前台应用采用Sharding-JDBC，根据业务场景的差异主要分为三种方案。
分库（用户）
问题解析：头部企业日活高并发高，单独分库避免干扰其他企业用户，用户数据的增长缓慢可以不分表。
拆分维度：企业ID分库
拆分策略：头部企业单独库、非头部企业一个库
分库分表（订单）
问题解析：订单数据增长速度较快，在分库之余需要分表。
拆分维度：企业ID分库、用户ID分表
拆分策略：头部企业单独库、非头部企业一个库，分库之后用户ID取模拆分表
单库分表（附件）
问题解析：附件数据特点是并发量不大，只需要解决数据增长问题，所以单库IO足以支撑的情况下分表即可。
拆分维度：用户ID分表
拆分策略：用户ID取模分表
问题一：分布式事务
分布式事务过于复杂也是分布式系统最难处理的问题，由于篇幅有限，后续会开篇专讲这一块内容。
问题二：分布式ID
问题三：跨片查询
举个例子，以用户id分片之后，需要根据企业id查询企业所有用户信息。
sharding针对跨片查询也是能够支持的，本质上sharding的跨片查询是采用同时查询多个分片的数据，然后聚合结果返回，这个方式对资源耗费比较大，特别是对数据库连接资源的消耗。
假设分4个数据库，8个表，则sharding会同时发出32个SQL去查询。一下子消耗掉了32个连接；
特别是针对单库分表的情况要注意，假设单库分64个表，则要消耗64个连接。如果我们部署了2个节点，这个时候两个节点同时查询的话，就会遇到数据库连接数上限问题（mysql默认100连接数）
问题四：分片扩容
随着数据增长，每个片区的数据也会达到瓶颈，这个时候需要将原有的分片数量进行增加。
由于增加了片区，原先的hash规则也跟着变化，造成了需要将旧数据做迁移。
假设原先1个亿的数据，hash分64个表，现在增长到50亿的数据，需要扩容到128个表，一旦扩容就需要将这50亿的数据做一次迁移，迁移成本是无法想象的。
问题五：一致性哈希
首先，求出每个 服务器的hash值 ，将其配置到一个 0~2^n 的圆环上 （n通常取32）
其次，用同样的方法求出待 存储对象的主键 hash值 ，也将其配置到这个圆环上。
然后，从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
一致性hash的优点在于加入和删除节点时只会影响到在哈希环中相邻的节点，而对其他节点没有影响。
所以使用一致性哈希在集群扩容过程中可以减少数据的迁移。
好了，这次分享到这里，我们日常的实践可能只会用到其中一种方案，但它不是数据库架构的全貌，打开技术视野，才能更好地把存储工具利用起来。
老规矩，一键三连，日入两千，点赞在看，年薪百万！
7年Java老兵，小米主题设计师，手机输入法设计师，ProcessOn特邀讲师。
曾涉猎航空、电信、IoT、垂直电商产品研发，现就职于某知名电商企业。
技术公众号 【架构师修行录】 号主，专注于分享日常架构、技术、职场干货，Java Goals：架构师。
交个朋友，一起成长！
