开发者学堂课程【云数据库选型及架构设计：典型案例分析】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址:https://developer.aliyun.com/learning/course/596/detail/8558
典型案例分析
目录
一、车联网行业典型案例
二、金融行业典型案例
三、地理信息服务行业典型案例
四、餐饮行业典型案例
本节是介绍几个相关的案例。帮助了解目前阿里云的用户是怎么配合使用阿里云数据库产品的，以及使用这些产品之后解决了什么样的问题，带来了什么样的业务价值。
一、车联网行业典型案例
1.终端上传数据报文
2.通过规则引擎解析成数据项
3.通过消息队列写入 HBase 及 RedisRedis 是用来提供车辆实时状态的查询
4.HBase 提供车辆历史数据的查询
5.OSS 存储灾备数据
这个案例主要用到了 Redis 数据库和 Hbase 数据库，其业务逻辑首先是车联网的实施的终端会实时的上传一些数据报文，这些数据报文通过一些规则引擎解析成一些数据项，然后通过消息队列将这些数据向写入到 Redis 跟 Hbase 数据库。
Redis 数据库主要是存储。比如车辆实时状态的一些查询的实时性的一些缓存的一些数据库。Hbase 是把车辆历史数据都完全上传，可以做一些基于历史的一些大数据的一些分期，跟报表的一些展示。
OSS 存储主要是用来存储一些灾备的一些数据，用这套体系架构，首先解决了一个车联网，实时要求非常高的一些业务的诉求，解决了一个车联网数据。存储量非常大的一个业务的一个痛点。
二．金融行业典型案例
业务诉求:
两地三中心建设
故障快速恢复
保证业务可用性和连续性
实现方式:跨可用区的金融版 MySQL+DTS 异地同步。
金融行业在数据库层面上有一定特殊性，因为其对于数据的可能性跟安全以及数据的强一致性是有着非常高的一些要求的。所以在金融行业时用户使用数据库的时候，金融行业有很多的务实的一个需求。第一个是它希望是能够做到一个两地三中心的一个架构；第二个是希望它能够快速的恢复，不管是机房层面还是数据库存储层面，甚至地域性的层面发生一些故障时，是能够很好的做数据库切换来接管业务的，去保证业务的连续性和可用性的需求。
目前这些金融客户采用的数据库的架构就是在主区也会选用一个金融版 MySql 去保证数据的强一致性跟跨机房的一个容灾的一个驱穹，然后在这基础之上，会通过DTS 数据传输的方式，将数据同步一份到一个异地的灾备实例里面去，从而完整的构建成一个两地三中心的，甚至 n 中心的一个整体的容灾的一个架构。
三．地理信息服务行业典型案例
业务诉求:
1.更多的计算、存储空间需求
2.综合成本可控
3.系统可用性保障
4.管理便捷的需求
5.云数据库弹性︰
云端弹性资源机制，使得 MongoDB 集群可以随时添加节点，实现计算和存储的双向扩容。同时，基于其灵活的售卖，可以根据业务动态增删 mongos 节点，方便抵挡业务高峰。
6.定制 snapshot
阿里云内核独家定制逻辑 snapshot 能力，支持在数据大量写入时，读取操作依旧读取数据更新前的数据，在数据更新完成后，读取才切换到最新数据上，该功能使得业务无需再部署冗余系统，减少近50%成本。
7.降低管理运维成本︰
自动化备份系统，快速恢复功能，监控报警及审计功能都大大解放了运维资源的投入。
这个案例是客户如何使用阿里云的 Mongo 数据库解决地理信息服务存储的需求。
客户在使用此案例过程中，更多的业务诉求首先希望有更多的一个存储的一个空间需求，而且综合成本上很高的，技能的可用性是能够有一个很好的保证的，然后管理起来也非常的便捷，或者后续扩容时，也能够非常的快速和灵活。
云 Mongo 数据库刚好是从各个点很好的去解决这些方面的一些需求。比如说像弹性方面，Mongo 数据库集群是可以随时添加一些节点去提升整个剧情的服务能力的。而且在业务高峰期过之后，用户也是可以根据自己的选择去删除掉一些节点，从而去灵活的控制成本。
在快照方面，阿里云内核是单独做了一个 Mongo DB 逻辑快照的一个能力，它能够支持在数据大量写入时，也可以去通过快照的方式去查一些历史数据，然后从而保证业务的各种不同业务场景下的一些查询的一些需求，也不需要客户去部署一些冗余的一些系统去做这个事情，从而中间成本上市会有一个明显的降低。
然后管理运维成本上来看，日常 Mongo 数据库的管理工作已经通过控制台的方式整体进行了一个统一的实现，所以客户使用这套架构时，管理因为成本也会得到一个明显的控制。
四．餐饮行业典型案例
1.海量数据存储
POLARDB 采用分布式块存储设计和文件系统，使得存储容量不限制于单节点的规格，能够轻松扩展，应对上百TB级别的数据规模。不再为数据增长而担忧。采用共享存储的数据机制，存储成本也不高。
2.数据安全可靠，高可用保障
采用白名单、VPC 网络、SSL 加密、数据多副本存储等全方位手段，对数据库数据访问、存储、管理等各个环节提供安全保障。采用 Active-Active 的高可用集群架构，直接通过可读写的主节点和只读的 Replica 节点之间进行 Failover 切换，与传统的 Active-Standby 相比，用同样成本带来了更好的系统访问性能。
3.高并发读写
POLARDB 采用读写分离架构，支持多路应用服务器并发访问。程序只需将数据量连接地址修改为读写分离地址，写请求会自动发往主实例，读请求会自动根据各实例的负载（当前未完成的请求数)发往主实例或只读实例。轻松实现了读写分离的架构，提高了系统的性能，可用随时添加只读实例，即可不断扩展系统的处理能力，应用程序上无需做任何修改。
解析：
之所以选择 POLARDB 数据库主要因为围绕以下几点:
1.第一点是 POLARDB 的海量数据存储的能力，因为客户考虑到后期业务发展，可能传统的 MySql 数据库所支撑的容量会有一定的瓶颈，后续还会涉及到做分布分表一些复杂操作。
2.POLARDB 数据库存储层面上可以自动扩容，所以不用担心数据增长会影响后面的一些数据库的一些重新架构语音应用的一些改造，考虑到在数据安全可靠方面高可用保障方面，整体的一些架构也是非常的灵活，很好的满足这些业务需求。
3.另外的一点是 POLARDB 是能够灵活的去增加一个只读实力来支撑高并发场景下的一些高性能的。整体弹进账会比传统 MySql 数据库有一个很明显的一个提升。这些弹性的扩充，对于客户的应用是相对来说比较透明，客户不用修改任何的一些配置，可以很灵活的使用到这些 POLARDB 带来的一些高性能，高容量的一些优势。
