首页 文章 精选 留言 我的

精选列表

搜索[第四期热点征文-C]，共10019篇文章
优秀的个人博客,低调大师

热点推荐：为什么JVM需要GC

社区内有人发起了一个讨论，关于JVM是否一定需要GC？他们认为应用程序的回收目标是构建一个仅用来处理内存分配，而不执行任何真正的内存回收操作的 GC。即仅当可用的 Java 堆耗尽的时候，才进行顺序的 JVM 停顿操作。 首先需要理解为什么需要GC。随着应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。 社区的需求是尽量减少对应用程序的正常执行干扰，这也是业界目标。Oracle在JDK7时发布G1 GC的目的是为了减少应用程序停顿发生的可能性，让我们通过本文来了解G1 GC所做的工作。 JVM发展历史简介 还记得机器猫吗？他和康夫有一张书桌，书桌的抽屉其实是一个时空穿梭通道，让我们操作机器猫的时空机器，回到1998年。那年的12月8日，第二代Java平台的企业版J2EE正式对外发布。为了配合企业级应用落地，1999年4月27日，Java程序的舞台—Java HotSpot Virtual Machine（以下简称HotSpot ）正式对外发布，并从这之后发布的JDK1.3版本开始，HotSpot成为Sun JDK的默认虚拟机。 GC发展历史简介 1999年随JDK1.3.1一起来的是串行方式的Serial GC ，它是第一款GC，并且这只是起点。此后，JDK1.4和J2SE1.3相继发布。2002年2月26日，J2SE1.4发布，Parallel GC 和Concurrent Mark Sweep （CMS）GC跟随JDK1.4.2一起发布，并且Parallel GC在JDK6之后成为HotSpot默认GC。 HotSpot有这么多的垃圾回收器，那么如果有人问，Serial GC、Parallel GC、Concurrent Mark Sweep GC这三个GC有什么不同呢？请记住以下口令： 如果你想要最小化地使用内存和并行开销，请选Serial GC； 如果你想要最大化应用程序的吞吐量，请选Parallel GC； 如果你想要最小化GC的中断或停顿时间，请选CMS GC。 那么问题来了，既然我们已经有了上面三个强大的GC，为什么还要发布Garbage First（G1）GC？原因就在于应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。 为什么名字叫做Garbage First（G1）呢？ 因为G1是一个并行回收器，它把堆内存分割为很多不相关的区间（Region），每个区间可以属于老年代或者年轻代，并且每个年龄代区间可以是物理上不连续的。 老年代区间这个设计理念本身是为了服务于并行后台线程，这些线程的主要工作是寻找未被引用的对象。而这样就会产生一种现象，即某些区间的垃圾（未被引用对象）多于其他的区间。 垃圾回收时实则都是需要停下应用程序的，不然就没有办法防治应用程序的干扰 ，然后G1 GC可以集中精力在垃圾最多的区间上，并且只会费一点点时间就可以清空这些区间里的垃圾，腾出完全空闲的区间。 绕来绕去终于明白了，由于这种方式的侧重点在于处理垃圾最多的区间，所以我们给G1一个名字：垃圾优先（Garbage First）。 G1 GC基本思想 G1 GC是一个压缩收集器，它基于回收最大量的垃圾原理进行设计。G1 GC利用递增、并行、独占暂停这些属性，通过拷贝方式完成压缩目标。此外，它也借助并行、多阶段并行标记这些方式来帮助减少标记、重标记、清除暂停的停顿时间，让停顿时间最小化是它的设计目标之一。 G1回收器是在JDK1.7中正式投入使用的全新的垃圾回收器，从长期目标来看，它是为了取代CMS 回收器。G1回收器拥有独特的垃圾回收策略，这和之前提到的回收器截然不同。从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区，但从堆的结构上看，它并不要求整个Eden区、年轻代或者老年代在物理上都是连续。 综合来说，G1使用了全新的分区算法，其特点如下所示： 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力； 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况； 分代GC：G1依然是一个分代收集器，但是和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代； 空间整理：G1在回收过程中，会进行适当的对象移动，不像CMS只是简单地标记清理对象。在若干次GC后，CMS必须进行一次碎片整理。而G1不同，它每次回收都会有效地复制对象，减少空间碎片，进而提升内部循环速度。 可预见性：由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。 随着G1 GC的出现，GC从传统的连续堆内存布局设计，逐渐走向不连续内存块，这是通过引入Region概念实现，也就是说，由一堆不连续的Region组成了堆内存。其实也不能说是不连续的，只是它从传统的物理连续逐渐改变为逻辑上的连续，这是通过Region的动态分配方式实现的，我们可以把一个Region分配给Eden、Survivor、老年代、大对象区间、空闲区间等的任意一个，而不是固定它的作用，因为越是固定，越是呆板。 G1 GC垃圾回收机制 通过市场的力量，不断淘汰旧的行业，把有限的资源让给那些竞争力更强、利润率更高的企业。类似地，硅谷也在不断淘汰过时的人员，从全世界吸收新鲜血液。经过半个多世纪的发展，在硅谷地区便形成只有卓越才能生存的文化。本着这样的理念，GC承担了淘汰垃圾、保存优良资产的任务。 G1 GC在回收暂停阶段会回收最大量的堆内区间（Region），这是它的设计目标，通过回收区间达到回收垃圾的目的。这里只有一个例外情况，这个例外发生在并行标记阶段的清除（Cleanup）步骤，如果G1 GC在清除步骤发现所有的区间都是由可回收垃圾组成的，那么它会立即回收这些区间，并且将这些区间插入到一个基于LinkedList实现的空闲区间队列里，以待后用。因此，释放这些区间并不需要等待下一个垃圾回收中断，它是实时执行的，即清除阶段起到了最后一道把控作用。这是G1 GC和之前的几代GC的一大差别。 G1 GC的垃圾回收循环由三个主要类型组成： 年轻代循环 多步骤并行标记循环 混合收集循环 Full GC 在年轻代回收期，G1 GC暂停应用程序线程，然后从年轻代区间移动存活对象到Survivor区间或者老年区间，也有可能是两个区间都会涉及。对于一个混合回收期，G1 GC从老年区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。 G1的区间设计灵感 为了加快GC的回收速度，HotSpot的历代GC都有自己的不同的设计方案，区间概念在软件设计、架构领域并不是一个新名词，关系型数据库、列式数据库最先使用这个概念提升数据存、取速度，软件架构设计时也广泛使用这样的分区概念加快数据交换、计算。 为什么会有区间这个设计想法？大家一定看过电视剧《大宅门》吧？大宅门所描述的北京知名医术世家白家是这本电视剧的主角。白家有三兄弟，没有分家之前，由老爷子一手掌管全家，老爷子看似是个精明人，实质是个糊涂的人，否则也不会弄得后来白家家破人散。白家的三兄弟在没有分家之前，老大一家很老实，老二很懦弱，性格像女人，虽然肚子里明白道理，但是不敢出来做主。老三年轻时混蛋一个，每次出外采购药材都要私吞家里的银两，造成账目混乱。老大为了家庭和睦，一直在私下倒贴银两，让老爷子能够看到一本正常的账目。这样的一家子聚在一起，迟早家庭内部会出现问题，倒不如分家，你也不用算计家里的钱了，分给你，分给你的钱有本事守住，没本事就一直拮据下去吧。这就是最原始的分区（Region）概念。 我们回到技术，看看HBase的RegionServer设计方式。在HBase内部，所有的用户数据以及元数据的请求，在经过Region的定位，最终会落在RegionServer上，并由RegionServer实现数据的读写操作。RegionServer是HBase集群运行在每个工作节点上的服务。它是整个HBase系统的关键所在，一方面它维护了Region的状态，提供了对于Region的管理和服务；另一方面，它与Master交互，上传Region的负载信息上传，参与Master的分布式协调管理。 HRegionServer与HMaster以及Client之间采用RPC协议进行通信。HRegionServer向HMaster定期汇报节点的负载状况，包括RS内存使用状态、在线状态的Region等信息。在该过程中HRegionServer扮演了RPC客户端的角色，而HMaster扮演了RPC服务器端的角色。HRegionServer内置的RpcServer实现了数据更新、读取、删除的操作，以及Region涉及到Flush、Compaction、Open、Close、Load文件等功能性操作。 Region是HBase数据存储和管理的基本单位。HBase使用RowKey将表水平切割成多个HRegion，从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey（第一个HRegion的StartKey为空，最后一个HRegion的EndKey为空），由于RowKey是排序的，因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。HRegion由HMaster分配到相应的HRegionServer中，然后由HRegionServer负责HRegion的启动和管理，和Client的通信，负责数据的读(使用HDFS)。每个HRegionServer可以同时管理1000个左右的HRegion。 再来看看软件系统架构方面的分区设计。以任务调度为例，假设我们有一个中心调度服务，那么当数据量不断增多，这个中心调度服务一定会遇到性能瓶颈，因为所有的请求都会最终指向它。为了解决这个性能瓶颈，我们可以将任务调度拆分为多个服务，即这多个服务都可以处理任务调度工作，那么问题来了，每个任务调度服务处理的源数据是否需要完全一致？ 根据华为公司发布的专利发明，显示他们对于每一个任务调度服务有数据来源区分的操作，即按照任务调度数量对源数据进行划分，比如3个任务调度服务，那么源数据按照行号对3取余的方式划分，如果运行了一段时间之后，任务调度服务出现了数量上的增减，那么这个取余划分需要重新进行，要按照那个时候的任务调度数量重新划分区间。 回到G1。在G1中，堆被平均分成若干个大小相等的区域（Region）。每个Region都有一个关联的Remembered Set（简称RS），RS的数据结构是Hash表，里面的数据是Card Table （堆中每512byte映射在card table 1byte）。 简单的说RS里面存在的是Region中存活对象的指针。当Region中数据发生变化时，首先反映到Card Table中的一个或多个Card上，RS通过扫描内部的Card Table得知Region中内存使用情况和存活对象。在使用Region过程中，如果Region被填满了，分配内存的线程会重新选择一个新的Region，空闲Region被组织到一个基于链表的数据结构（LinkedList）里面，这样可以快速找到新的Region。 总结 没有GC机制的JVM是不能想象的，我们只能通过不断优化它的使用、不断调整自己的应用程序，避免出现大量垃圾，而不是一味认为GC造成了应用程序问题。 G1GC优化参考文档 作者介绍 周明耀，2004年毕业于浙江大学，工学硕士，国外投资银行12年工作经验，4年分布式系统、物联网工作经验，10年技术团队管理经验。IBM开发者论坛专家作者、InfoQ专栏作者，著有《大话Java性能优化》、《深入理解JVM&G1 GC》，提交分布式计算领域发明专利超过15项。 来源：51CTO
2017-07-31
优秀的个人博客,低调大师

【AWS征文】AWS安全加固-Fortinet AWS 安全解决方案

作者：昱坤 在公有云方案日益火爆的今天，公有云应用越来越广泛。随之而来的，公有云也遇到了一些挑战：  传统数据中心产品不一定支持云环境 传统的产品不一定支持云弹性的部署以及模块化的部署 云架构的部署思路与传统物理环境部署环境完全不同 传统的安全防护很难在多云环境提供统一安全解决方案 遇到最多的问题就是：我们云环境一定要和物理数据中心架构一样 而在企业进行公有云迁移时对于安全和自动化的要求，AWS上有了新的安全自动部署方案： 在该方案中，可以将防火墙部署在Transit VPC中，以实现VPC与VPC间/VPC与Internet间等的安全加固需求。此文仅介绍Fortinet AWS 的安全解决方案。 Fortinet云部署实例要求 如果要在AWS上部署FortiGate-VM，那么实例需要满足以下要求： Fortinet常见云部署模式 针对AWS云上部署，Fortinet提供两种常见的部署方案： NGFW 和ELB部署形式  两个AZ的FW与WAF工作在AA模式 入向流量通过ELB负载分摊 FW开启NGFW威胁检测功能 FW将流量映射至内部ELB FQDN NGFW以及WAF 和ELB部署形式  FW与WAF完全集成将HTTP转至WAF WAF对HTTP流量进行深度检测 WAF将HTTP流量映射至内部ELB 在该部署模式下，三明治式的部署架构是部署WAF的最佳实践： 入向流量通过ALB负载，并基于内容分流； WAF专注于管理高级WEB安全配置； 两种高级防御模式 • 黑名单提供特征库防御，IP信誉库，HTTP协议规范，防病毒.DLP，高级防御规则，高级APT防护等功能 • 白名单提供网站详细参数设定，扫描报告导入，应用自学，Bot机器学习，参数机器学习等功能云部署的高可用性 Fortinet云部署HA有两种方案： 方案一：  由于AWS VPC中不支持二层协议，所以不能在AWS中运行VRRP HA使用主备模式部署在相同AZ，心跳使用3层 根据事件或SLA自动切换主备 主备切换会自动调用AWS API，备设备将主设备上的secondary IP和EIP切换至备设备 同时备设备将指向主设备网卡的下一条指向自己 方案二：  FortiGate部署在两个不通的可用区，子网信息并不相同 通过Fortinet利用AWS的原生服务AWS API Gateway、Cloudwatch、Lambda构建了一套自动切换VPC路由表的解决方案 当FortiGate自己发现故障，会通过联动API Gateway触发Lambda切换VPC路由表 当Cloud Watch发现设备故障，同样会触发Lambda切换VPC路由表自动扩展模式 自动扩展模式： 在面向公网侧部署NLB，保障公网IP可以透传到FortiGate侧 CloudWatch持续监控FortiGate CPU及MEM信息触发Lambda Lambda在Autoscale成员中增加FW并通过API通知FW同步配置 FW同步完配置通过API通知Lambda Lambda更新ELB配置 DynamoDB存储Autoscaling 状态信息 支持PAYG，Hybrid部署
2020-09-03
优秀的个人博客,低调大师

【AWS征文】带你轻松迁移数据库到 AWS

如今，企业上云离不开数据库上云。然而，云上有很多数据库类型，企业该如何选择？将数据库迁移到云端，该有哪些步骤呢？不同的业务场景下，企业该如何选择？本文将介绍 AWS 各种常用数据库特性，以及如何满足客户不同业务需求，并列举数据库迁移案例为大家演示如何轻松便捷的把数据库迁移上云。 一、AWS 数据库概览 在这个互联网极其发达的时代，我们每个人会接收以及生产各式各样的信息，数据的重要性已经***到每个角落，成为每个行业发展和变革的必要元素。我们日常使用的手机应用，比如微信、支付宝、微博等，里面的数据都是需要数据库来进行存储，不同的应用会使用不同类别的数据库，甚至同一个应用可能同时使用多种数据库。 应用离开了数据库就像鱼儿离开了水，由此可见数据库在当今互联网的重要性。我们甚至可以说当今世界最宝贵的资源不再是石油，而是数据。随着业务的快速发展，全球化业务新兴需求增加，本地传统数据库已经无法为快速发展的业务提供支持，我们需要探索一种新的方式，把本地数据库迁移到云中，利用云中数据库的优势来解决本地数据库中遇到的瓶颈问题。 我对各家云厂商数据库种类做了一个比较，发现 AWS 为用户提供的数据库种类最为丰富，几乎把所有数据库相关的应用场景都捕捉到了。下面通过一个列表，来浏览一下 AWS 的数据库种类，其中关系型数据库最为丰富，也是目前应用使用最多的数据库。 以上这些数据库由 AWS 完全托管，用户不用去管理底层硬件系统升级维护等相关工作，这也是推荐使用全托管数据库而非自建数据库的原因。为了方便客户数据库迁移上云，AWS 还为客户提供了非常方便的迁移工具 DMS，帮助用户轻松经济高效的完成迁移任务。 那么面对这么多种类的数据库，尤其是一些新型数据库，我们从来没有使用过，我们该如何选择？我们需要从业务场景为出发点来分析使用哪种数据库，下面我对 AWS 数据库的使用场景做个简单的介绍，也让大家对 AWS 各种数据库的应用场景有一个大致了解。 数据库种类 应用场景 关系数据（RDS） 传统应用程序、ERP、CRM 、电子商务 键值数据（DynamoDB） 高流量 Web 应用、电子商务系统、游戏应用程序、微服务 宽列数据（Keyspaces） 用于设备维护、队列管理和路线优化的大规模工业应用程序 文档数据（DocumentDB） 内容管理、目录、用户配置文件、移动和 Web 应用程序 内存数据（ElasticCache） 缓存、会话管理、游戏排行榜、地理空间应用程序 图数据（Neptune） 欺诈检测、社交网络、推荐引擎、知识图谱 时序数据（Timestream） IoT 应用、开发运营和工业遥测 分类账数据（QLDB） 系统记录、供应链、注册、银行事务 初步了解 AWS 各项数据库的应用场景之后，我们详细介绍 AWS 各项数据库特性，以及 AWS 数据库如何满足用户在各种业务场景下面的需求。 数据库家族 关系型数据库 关系型数据库是起源非常早的数据库，也是目前各种应用使用最多的数据库。我们使用各种应用都需要注册用户，这些用户数据存放在关系型数据库里面；你在电商网站下了一个订单，订单也是存放在关系型数据库里面；我们访问的网站，其后台数据也是存放在关系型数据库里面。所以说关系型数据库无所不在。 说到 AWS 的关系型数据库，那不得不说一下 Amazon Aurora，Aurora 是 AWS 专为云而打造的云原生数据库，它兼容 MySQL 和 PostgreSQL，它可以支撑我们各种关系型数据库的应用场景，性能好、易扩展、安全、便于管理，Aurora 如此好用，也依托于它下面的一些特性： 性价比：吞吐量为标准 MySQL 的五倍，标准 PostgreSQL 的三倍，成本只有商业数据库的十分之一。 扩展性：基于共享存储，主从复制延迟很低，可跨三个可用区扩展至最多 15 个只读副本。 可用性与持久性：具有容错能力的自我修复存储；跨三个可用区建立六个数据副本；持续备份至 S3。 安全性：VPC 网络隔离、静态/传输数据加密、满足大多数地区合规性要求。 全球数据库：数据库跨越多个 AWS 地区同步复制，将数据库置于用户端，可以实现低延迟（典型延迟小于 1 秒）的本地读取和跨区域灾难恢复。 无服务器：可以根据工作负载自动扩容缩容，无需关心底层硬件扩展，适合业务波动的应用。 Aurora 具有很多传统数据库不具有的特性，这样让 Aurora 成为关系型数据库的首选。不过如果你不想更换数据库类型，把本地现有的数据库迁移到云中，AWS 还为用户提供 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle 等关系型数据库，客户可选择相同的数据库引擎进行迁移。并且这些数据库依托于 AWS 强大的基础设施和管理，同样安全稳定。 如果 Aurora 非常吸引你，而你现在用的是 SQL Server 或者 Oracle，那该怎么办？不用担心，AWS 为客户提供了 Schema Conversion Tool、DMS 这两个服务，可以帮助客户评估并且转换数据库对象，非常便捷地将本地数据库迁移到 Aurora。 键值数据库 互联网发展到今天，数据表越来越大，有的应用要求写得快、读的快等需求。关系型数据库已经无法满足我们的需求，因此 NoSQL 数据库也就诞生了。我们把一些不需要关系查询，要求读写快的应用数据放置在 NoSQL 数据库里面来解决性能问题。 考虑到客户的需求，AWS 也为客户提供了自研的 NoSQL 数据库 Amazon DynamoDB，它支持键值存储，也支持文档存储，特别以键值存储为核心，面对海量数据，性能非常强悍。因其由 AWS 完全托管，所以也是无服务器架构中的重要一员。 扩展性：可自动纵向扩展和缩减表，以针对容量做出调整并保持性能，提供任意级别的请求流量。 高性能：对于一般的请求，DynamoDB 在个位数毫秒内可以完成，而且处理请求的速度不会随着数据量的增加而减慢。 分布式：无中心化架构，一个表上的数据可以分布到几百台机器上。 我也在 AWS 官方渠道了解到，汇量科技是一家广告公司，他们也大量使用了 AWS 的服务，尤其是对广告点击的数据，正是采用了 DynamoDB 数据存储，可以支撑 2019 年日均广告请求量 600 亿次，峰值高达 1000 亿次。如此巨大的请求量，放在关系型数据库将无法支撑，由此可见 DynamoDB 在这种应用场景性能多么强悍。 文档数据库 JSON 数据无数不在，它是一种非常灵活的格式，你可以很方便地修改一条数据的 Schema。它是一种轻量级的数据交换格式，目前使用最广泛的 API 标准 RESTfull API，它的输出标准也是 JSON。使用 JSON 进行数据建模最符合人类语言的逻辑。以上这些使用场景，我们都需要一种文档数据库来存储 JSON 数据，它既不是关系型数据库，也不是键值数据库。 哪些应用场景会用到文档数据库呢？因为 JSON 数据的灵活，文档数据已经***到各个领域，比如在游戏中，存储用户信息，装备积分等；在物流中，存储订单信息，订单状态；在社交中，存储用户信息以及用户发表的朋友圈信息；在视频直播中，存储用户信息和礼物信息等。 为了满足客户这些使用场景，AWS 为客户提供了 DocumentDB 数据库，见名知意，它是一个云原生的文档数据库，与 MongoDB 兼容，你可以把现有的 MongoDB 数据库通过 DMS 或 mongodump/mongorestore 等原生方式迁移上 AWS。 DocumentDB 扩展性很强，水平扩展在分钟级别，最多可以扩展到 15 个读副本；垂直扩展也在分钟级，最高扩展至 768 GiB 内存；存储可以自动扩展，最高支持 64TB。这些特性都是我们在自建数据库很难实现的。 内存数据库 如今的应用越做越大，很多都已经开始进行分布式或者微服务架构，这时候就需要一个存储库来储存用户的会话信息，不然用户可能处于频繁的登陆状态；还有应用要求提升数据查询速度，这就需要给数据库添加缓存层等。以上这些应用场景都会需要内存数据库。 那么 AWS 同样在云中为客户提供了完全托管的内存数据库 Amazon ElastiCache，客户可以把一些热数据、会话数据、消息数据、排行数据等存放在其中，以加速数据的存取速度。它支持两种存储引擎，Memcached 和 Redis。 极致性能：能够支持要求最严苛且需要亚毫秒级响应时间的应用程序。 轻松扩展：通过使用 AWS 管理控制台或者简单的 API，用户可以根据应用需要添加或删除缓存集群中的节点。 安全性：支持 Amazon VPC，可以进行网络隔离。通过安全组来管理集群的访问权限。 高可用：可将 2 到 6 个节点归入一个具有副本的集群，如果一个节点出于任何原因发生故障，您不会丢失所有数据。 图数据库 关系型数据库有了，键值和内存数据库也有了，已经基本满足大部分应用的日常需求，对于 AWS 来说，这还不够。用户还会面临性能和 schema 变更不易的问题，因此 AWS 推出了图数据库 Neptune。 使用图形数据库处理社交网络数据非常高效，Amazon Neptune 可以快速轻松地处理大量的用户配置文件和交互，从而构建社交网络应用程序。 时序数据库 顾名思义，时序数据库是和时间相关的数据库。因为很多对数据的查新都是以时间段为基础的， 适用于 IoT 和运营应用程序。因此 AWS 为用户提供了 Amazon Timestream，专门处理时序数据，目前还处于注册预览版。 分类账数据库 分类账数据库的使用场景也很好理解，最适合的场景是“记账本”。“账本”是不能被更改的，每一笔记录都不能被改动，被忠实的记录下来，以备查询。Amazon Quantum Ledger Database 就应运而生了。 这听起来和“区块链”有点关系，不过 QLDB 是有中心的，而“区块链”是去中心化的，那么你可能会问，AWS 有没有去中心化的数据库，回答是有的，那就是 Amazon Managed Blockchain。我们很难去想 AWS 到底不存在什么数据库，用户需要的它有，用户用不到的它也有，可以说达到了“应有尽有”的程度。 迁移工具 介绍了这么多的数据库，以及各种数据库的使用场景和特性，几乎满足日常应用的所有需求，那我们肯定是想知道如何使用这些数据库，以及如何把目前本地自建的数据库迁移到云中。下面我们将介绍 AWS 为客户提供的迁移神器 AWS Database Migration Service，以及 DMS 如何帮助客户便捷高效地把数据迁移到云中的数据库。 同样 DMS 也是完全托管的，这让我们把主要精力放在迁移任务上面来。DMS 支持多种数据库作为迁移的源，也支持多种数据库作为迁移的目标，从下面的表格可以详细了解支持哪些数据库： 数据迁移的源 数据迁移的目标 Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、MongoDB、DB2 LUW、Azure SQL、Amazon RDS、S3 Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、Amazon RDS、Amazon Redshift、Amazon S3、Amazon DynamoDB、Amazon Elasticsearch Service、Amazon Kinesis Data Streams、Amazon DocumentDB、Amazon Neptune、Apache Kafka 我们可以从表格中看到各种数据库引擎，AWS DMS 支持同构数据库迁移，如 MySQL 迁移到 MySQL，也支持异构数据迁移，如 Oracle 到 MySQL，在进行异构数据库迁移的过程，AWS 还为用户提供一款工具 AWS Schema Conversion Tool，可以使用 AWS SCT 将源数据库架构和大部分对象自动转换为与目标数据库兼容的格式。 对 DMS 的总结，可以简单概括为下面几个小特性： 简单易用 最少停机时间 持续数据复制 多数据源支持 运行可靠 AWS DMS 可以成为复制和迁移数据库的最佳工具，它可以帮助用户将数据库工作负载迁移到 AWS 并更改数据库引擎，同时最大程度地减少停机时间。根据 AWS 的说明，使用 AWS DMS 已经进行了 20,000 个数据库到 AWS 云的迁移。由于使用该产品获得了如此广泛的成功，因此没有理由不将数据库迁移到 AWS，那么下面就开始我们的数据库迁移之旅吧。 迁移方式 所有的数据库都有自己的备份还原工具，使用这些工具我们可以方便的进行数据离线迁移，但是会造成较长的停机时间，主要看数据量的大小。如果需要最小的停机时间，那 DMS 是最佳选择。下面大致列举了各种迁移方式对业务的一个影响程度，可以根据自己的实际情况进行选择。 因素 离线（转储） 混合 在线（DMS） 复杂度 非常简单 复杂 中等 速度 快 中等 慢 停机时间 高 中 低 二、云上数据库迁移实践 迁移解决方案 我们在本地数据中心有各式各样的自建数据库，如果对数据库迁移上云，我们该如何选择云中的数据库呢，我下面简单整理了一个列表，针对不同的场景，我们可以选择对应的解决方案。 现有应用程序 MySQL ---> Amazon Aurora for MySQL，RDS for MySQL PostgreSQL ---> Amazon Aurora for PostgreSQL，RDS for PostgreSQL MariaDB ---> Amazon Aurora for MySQL，RDS for MariaDB Oracle ---> 利用 AWS SCT 检测复杂性因素 ---> Amazon Aurora，RDS for Oracle SQL Server ---> 利用 AWS SCT 检测复杂性因素 ---> Amazon Aurora，RDS for SQL Server MongoDB ---> DocumentDB 新的应用程序 如果不需要关系类功能 ---> Amazon DynamoDB 如果需要关系类功能 ---> Amazon Aurora 内存存储/缓存 Redis ---> Amazon ElasticCache Memcached ---> Amazon ElasticCache 时序数据 Amazon Timestream（注册预览版） 跟踪各应用程序变更、加密可验证性，具备中央可信权威 Amazon Quantum Ledger Database 迁移须知 数据库是任何应用程序的主要组件之一，因此我们必须谨慎地进行迁移。您需要知道数据库的大小，数据库内部表的大小以及数据库模式。 使用 AWS DMS 将数据迁移到 AWS 很简单。首先在 AWS 环境中创建复制实例，然后 AWS DMS 连接源数据库端点和目标数据库端点。迁移开始时，AWS DMS 会创建表，加载数据并同步数据库。整个复制任务都由复制实例承担，建议创建配置比较大的复制实例。 使用 AWS DMS 执行迁移的总体流程如下： 创建目标数据库。 复制架构。 创建 AWS DMS 复制实例。 定义源数据库和目标数据库的终端节点。 创建并执行迁移任务。 将 MySQL 数据迁移到 Aurora MySQL 这个案例是一个同构数据库迁移，相对来说比较简单，迁移的方案有三种，可以直接使用mysqldump导出数据，然后再导入到 Aurora，适合数据量不大的数据库，另外一种是直接把数据库的源文件复制到 S3 存储桶，可以使用 Xtrabackup 备份数据库然后传到 S3 中，然后用这些文件还原到 Aurora 数据库，适合比较大量的数据，不过这两种数据库都是离线传输，需要停机迁移。 针对实时在线迁移数据库，我们需要用到 AWS DMS，下面我将演示如何从一台 MySQL 数据库，实时迁移数据到 Aurora，对于源数据库，我们可以使用 AWS RDS，或者在 EC2 上面的自建数据库，或是其他云厂商的 MySQL 数据库，下面我选择使用在 EC2 上面自建的数据来进行演示，所以操作均在 AWS us-east-1 区域。 1、配置源数据库 源数据库我们已经有了，你可以创建一个只读权限的临时账户用于数据迁移，我们这里就直接用具有读写权限的账户演示。 2、创建 Aurora 数据库 首先我们在 AWS 控制台中创建一个 Aurora MySQL 数据库作为我们的目标数据库，因为不是主要介绍创建数据库，所以创建过程这里不再演示，创建完成之后，需要记录下数据库地址，账户密码，当然为了安全，你也可以单独创建一个用于迁移的临时账户。 3、创建复制实例 AWS DMS 复制实例执行源和目标之间的实际数据迁移。复制实例负责整个数据的迁移，对更改的数据进行缓存，所以说大一点的实例性能更好，缩短迁移时间。打开 AWS DMS 控制台，选择创建复制实例，注意网络方面的限制，需要复制实例可以连接到两个数据库。 4、创建 MySQL 终端节点 在 AWS DMS 控制台中，在导航窗格中选择 Endpoints (终端节点)。 5、创建 Aurora 终端节点 目标终端节点会更简单一写，因为是 AWS RDS，我们可以直接勾选。 6、创建迁移任务 迁移任务中的迁移类型我们选择复制现有数据以及持续复制变更的数据，记得源数据库开启 binlog 日志。 在表映射选项里面，选择告知 DMS 应该迁移哪些表，迁移过程中还可以对表名进行一些转换，我们这里就选择完全复制整个数据库。 7、监控迁移任务 再等待一段时间之后，我们可以在任务详情里面看到数据迁移完成，并且目标数据库数据检查没有问题。 我们可以看到，通过 DMS 仅仅需要简单几步就可以把数据库迁移到 AWS，并且源数据库变更数据会实时的更新到目标数据库中。 将 SQL Server 数据库迁移到 Aurora MySQL 这个案例是一个异构数据库迁移，我们会用到 AWS SCT 进行 Schema 转换，AWS DMS 支持从 RDS 迁移到 RDS，所以这次的源数据库 SQL Server 是 AWS RDS for SQL Server（Enterprise Edition）。 Schema 转换 1、在本地计算机安装 AWS SCT 需要在自己的电脑上面安装 AWS SCT 工具，以及连接 SQL Server 的 JDBC 驱动和 Aurora MySQL 的 JDBC 驱动。 驱动下载地址参照官方文档 https://docs.aws.amazon.com/zh_cn/SchemaConversionTool/latest/userguide/CHAP_Installing.html#CHAP_Installing.JDBCDrivers 然后启动 SCT，配置一下刚刚下载的 JDBC 驱动。 2、创建迁移项目 打开 AWS SCT，选择创建一个新项目，选择源和目标数据引擎。 分别连接 SQL Server 和 AWS Aurora 数据库。 勾选我们要迁移的数据库，右键选择 Create report。 查看报告，看看有没有问题，如果没有问题，我们就可以直接进行转换了。 我这边遇到一个存储过程 MySQL 不支持，我这边忽略掉，比较懂数据库的人员可以进行修正。 3、Schema 转换 问题处理掉之后，我们就可以进行 Schema 转换了，和前面一样，右键数据库，选择 Convert schema。 执行之后，很快我们在目标数据库看到了转换的 Schema。 数据迁移 对于 SQL Server 的数据迁移方式，我们选择一次性迁移，不进行持续复制，持续复制配置过程稍微复杂一些，需要对源数据库进行一些配置，需要持续复制的用户，可以参照 AWS 官方文档配置。 1、创建复制实例 打开 DMS 控制台，创建复制实例，同样注意网络情况，复制实例需要链接源和目标数据库。 2、创建 AWS DMS 源和目标终端节点 创建完终端节点之后，首先运行一下测试，可以连接成功即可。 3、创建迁移任务 可以按照我下面的表格选择来配置迁移任务。 Parameter Value Task identifier AuroraMigrationTask Replication instance replication-server Source database endpoint sqlserver Target database endpoint dst-mysql-instance-1 Migration type Migrate existing data Start task on create Checked Target table preparation mode Do nothing Include LOB columns in replication Limited LOB mode Max LOB size (KB) 32 Enable validation Unchecked Enable CloudWatch logs Checked 在表映射方面，我们可以这样设定，就不进行表名的转换了，然后创建任务即可。 Parameter Value Schema Tecno Table name % Action Include 4、检查目标库数据 可以看到，迁移任务完成，数据也都转移过来了。 至此我们完成了异构数据库迁移，整个过程会比同构数据库迁移麻烦一些，不过整体也是比较简单了。DMS 完全托管、按量付费、图形界面操作，是数据库上云的利器，推荐大家使用 DMS 对数据库迁移上云。 三、总结 AWS 数据库优势 在众多的云厂商中，我们为什么选择 AWS 数据库服务，AWS 还有哪些独特的优势呢？我主要总结以下几点： 成本优势 使用自建数据，企业首先需要支付一笔资金购买服务器，一些商业数据库的授权，需要再次支付一笔费用。如果迁移到 AWS 的自研数据库，客户不必再支付高昂的商业数据库授权，也不必再去花费大量资金去购买服务器，在云中，客户只需要按量付费，因此很多企业由于把数据库迁移到 AWS 而节省巨大费用支出。 从最近的 AWS 公告中，看到 AWS 帮助三星把数据从商业数据库 Oracle 迁移到了 Aurora，为三星每月的数据库成本降低了 44%，并让三星的数据库运行更加稳定。 完全托管 以上所说的几种数据库都是 AWS 完全托管的数据库，完全托管意味着零运维。首先客户不需要去维护硬件的生命周期、系统的补丁更新、高可用的部署、备份等。如果需要对数据库扩展，也只需点几下鼠标而已，非让方便，让 DBA 从复杂的数据库运维中解脱出来，专注于数据库性能调优。 全球优势 过去我们需要借助非常复杂的技术手段，花费大量的成本、甚至牺牲一定的可用性，才能实现快速、稳定、安全的跨区域的数据复制，现在只要在 AWS 云中轻轻点几下鼠标即可完成。 AWS 云现已在全球 24 个地理区域内运营着 77 个可用区，180个边缘站点等，为 AWS 相应全球数据库提供了基础保障。依托于 AWS 强大的基础设施，目前已经有三款数据库支持全球同步，延迟通常不超过 1 秒，可以满足目前大部分应用的需求。 对于关系型数据库的全球同步需求，Amazon Aurora Global Database 能够允许用户轻松实现跨区域的数据库部署，让用户轻松在区域之间复制数据和解决更新冲突，从而更加专注于应用程序的业务逻辑。 AWS 还提供了 Amazon DynamoDB Global Tables。它基于 DynamoDB 的全球覆盖范围构建，具有多区域、多主表的特性，可让全局分布式应用程序实现快速的本地读写性能，为用户提供一个完全托管的、多区域、多主的 Key-Value 类型数据库。 针对缓存数据库，在众多组织都在利用 Redis 为全球用户提供低延迟访问的背景下，AWS 为更好满足客户的需求，AWS 推出了 Amazon ElastiCache Global Datastore for Redis 全球缓存数据库，为用户提供数据跨区域复制，可以在一个区域写入数据，同时在其他区域读取数据，使缓存的数据更接近用户，减少网络延迟，并提高应用程序的响应能力。 心得与建议 当然，数据库迁移是一个庞大而复杂的工程，尤其将数据库迁移上公有云，除了数据库知识更需要了解公有云上网络，存储，虚拟化等一系列知识。但是，我们不应该仅仅将数据库上云看做一个复杂的任务，更应该把它当做一个优化我们数据库的契机，那么上云过程中有哪些注意事项和建议呢？ 对于一些允许停机的应用，这部分数据我们推荐使用离线迁移，整个操作比较简单，速度快，不容易出问题。 如果业务需要在线迁移，那么推荐使用 DMS 进行迁移，需要注意的是，在数据库切换之前先停掉源数据库写入，带数据完全同步到目标数据库之后进行数据库切换。 如果迁移的数据量比较大，建议选择配置比较大的复制实例，这样可以加速我们的复制速度。 如果您想要转换数据库引擎，在使用 SCT 进行 Schema 转换的时候可能会遇到一些目标数据库不支持的地方，请先联系 DBA 人员，对这些地方进行更改，满足之后再进行转换。
2020-08-11
优秀的个人博客,低调大师

K8s学习进阶月刊第四期 直击 KubeCon 2019 现场

欢迎订阅K8s学习进阶月刊 推荐阅读 分享 KubeCon 2019 （上海）关于 Serverless 及 Knative 相关演讲会议直击 KubeCon 2019 现场，阿里云 Hands-on Workshop 亮点回顾阿里云ACK简介及入门实践Knative 实践：人脸图片识别Windows 系统添加和修改 hosts 绑定的方法工作流在Kubernetes集群中的实践Istio 在阿里云容器服务的部署及流量治理实践Kubernetes Ingress日志分析入门云上快速搭建Serverless AI实验室CSI 系统介绍CSI 协议规范CSI介绍容器服务Windows Kubernetes使用阿里云日志服务来收集容器日志云厂商k8s认证鉴权流程介绍Istio on ACK集成生态(2): 扩展AlertManager集成钉
2019-06-27

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册