App数据层设计及云存储使用指南
引子：
随着腾讯开放战略的实施，越来越多的第三方应用，伴随着开放平台迅速成长。在应用从小到大的发展中所遇到的各类技术问题里，涉及数据层的问题可以说是最棘手、最难解决的方面，特别是在应用进入产品高峰期时，海量用户会带来很多设计初期难以现象的访问压力。
对于不涉及到数据的接入层或者逻辑层来说，遇到问题或者故障能够较快的进行定位和解决。但是对于数据层来说，由于数据状态的存在，以及对数据安全及可用性的要求，一旦出现问题，恢复时间可能非常长，影响深远。
对于开发者来说，如果选择自行解决数据层的问题，那么在后期其花费精力可能会达到其他方面的的数倍之多，这简直就是一个梦魇。因此，本文结合我们所看到过的应用开发的主流过程和经验教训，针对数据层的技术解决方案进行了探讨和分享，并就如何应用云存储进行快速开发提出了一些建议。文中所述观点，仅为一家之言，不代表腾讯官方观点，谨供参考。
第一部分：App开发中的数据之痛
根据我们对APP开发者研发过程的观察，面向数据层的解决方案大致有以下几个步骤：
1、直接使用单机Mysql来解决数据层的问题
大部分开发者最初直接用Mysql，因为这个阶段应用开发的主要矛盾并不是性能压力、容灾等方面，而是如何快速的实现功能和上线。而业界流行的LAMP架构具备上手快的优势，这时的数据层直接用单机Mysql就搭建起来了。
（1）好处：Mysql是一款非常知名的开源数据库软件，它功能丰富的、工具齐全，由于在全世界应用得非常广泛，基本上遇到任何问题都能够很快的找到讨论者和解决办法。同时在应用发展的早期数据库压力小，除了提供在线服务外，数据库往往还可以用来进行数据统计和经营分析。
（2）不足：数据库需要专职的DBA管理人员进行维护工作（如数据备份、主从切换等），对于外部开发者来说，往往是开发人员兼任DBA的角色，风险固然有，但由于设备数量少，一般不会出现大问题。只是偶尔的设备故障、软件配置不当和Bug等问题，对应用会有影响，但总体上能够承受。
2、 使用Memcached来分担读压力，使用Mysql来进行持久化
应用接入开放平台后，用户会增长非常快，整个系统迅速地要接受新的考验。Mysql主要利用本机内存进行缓存，受单机物理资源限制，难以胜任并发读写较高高的应用场景，而很多Social Game都有同时高并发读写的特点，这时会发现应用响应速度明显变慢。
这种情况下常见做法是在DB层之前加Cache，目前最常用的Cache就是Memcached，通过增加Cache设备和简单改造，可以快速上线。现在的数据层方案变成了Memcached缓存+Mysql持久化。Memcache应对读请求，Mysql应对写请求，效果立竿见影，DB压力迅速降低。
（1）好处：Memcached同Mysql一样，也是一款业内知名的开源软件。它具有接口简单、运行稳定、配置方便、性能出色的特点。
（2）不足：又多了一个模块需要开发者自己运营。而Cache层机器如果出现问题的话，可能会导致缓存丢失，命中率大幅下降，一旦出现这种DB层就非常危险，很容易产生严重的雪崩效应，恢复非常困难。另外，由于Cache只能用于应对读的压力，解决不了高并发写的问题，这个才是Social Game发展过程中最让人头疼的问题。
3、使用分布式MemCached和分库分表的Mysql集群方案
单机的Memcached和Mysql眼看着抵挡不住日益上升的访问压力了，开发者心里是有喜有忧，喜的是应用得到了用户的喜爱，忧的是要命的数据层又要面临严峻压力。既然发展到这个地步了，对数据层进行适当重构是必须的，业界关于分布式的方法可以借鉴的甚多，很多Memcached的SDK库已经支持分布了，Mysql也有分库分表的设计办法。经过一段时间的代码重构和数据搬迁后，数据层已经是个分布式的了。
（1）好处：现在的系统能够具备初步了较好的扩展性，可以根据用户活跃和访问情况进行扩容，用分布式的问题解决了单设备读写能力受限的困难。
（2）不足：虽然实现了系统的可扩展，可这并不意味着我们可以高枕无忧了。应用需要密切关注各服务的容量。对于Cache层来说，机器死机、扩容操作会导致缓存丢失，带来命中率大幅下降，而一旦DB压力过大，可能很长一段时间都缓不过劲来。而DB层的容错和扩容更是是令人神经紧绷，主备切换需要人工干预，还需要前端修改数据库接入IP、进行授权等若干配置；而扩容和数据搬迁操作一般只敢选在夜深人静的时候进行，一旦发现问题也要顶着巨大的压力去回滚和恢复数据，更是容易忙中出错。除此此外，要不要提前准备足够的资源也是令人十分纠结，准备多了会浪费资源，准备少了可能又满足不了业务的快速发展。而且Social Game的生命周期相对较短，往往数周之内迅速达到用户峰值，需要频繁的数据扩容和迁移，吃掉大量设备资源，接着就步入稳定和衰减期，又需要数据的合并和资源推出，对资源供应的要求非常高。而且此时的设备多，维护更加复杂，把如此庞大的精力都投在数据层显然是不明智的。
其实，我们可以活的更好的！
4、使用CMEM云存储解决方案
由于Social Game的SNS特性，App在拥有一定的用户规模后，数据量大，读写请求非常多，读写比接近，大量的写到数据层，数据层由于IO原因抗不住写压力。针对这类情况和腾讯在数据层研发过程中的实际经验，我们目前提供了两款高性能、低成本的云存储产品，分别是：
（1）NoSQL的云存储产品：Cmem。Cmem提供极高的并发读写能力，作为一款云存储产品，对用户透明的实现了自动容错、平滑扩容、数据备份、资源复用等一系列存储层的必要功能。将在线数据以Key-Value形式存放和访问，解决了大并发读写和令人头疼的数据层管理问题。
CMEM全称为Cloud Memory Storage，是腾讯提供的高性能内存级持久化存储服务。
CMEM基于一个存储键/值对的hashmap，具备内存级别的访问性能，并保证数据的持久性。
（2）SQL的云存储产品：CDB。CDB是兼容Mysql协议的云存储产品，以实例的方式进行Mysql数据库的供给，并将数据迁移、实例扩容、数据备份等工作都放在了云中，对逻辑层透明，减少了开发者对于DB层的维护成本。
CDB全称为Cloud Database，是腾讯提供的分布式数据存储服务。
CDB提供了高性能，高可靠的MySQL 集群服务，并且整合了备份，扩容，迁移等工具。
这个时候的设计模式是，将大量需要在线高效访问的数据通过Key-Value的形式放在Cmem中，将少量需要SQL功能的数据放在CDB中。
（1）好处：Cmem完全兼容memcached协议，CDB兼容Mysql协议，这样对于开发者来说基本无门槛。在开发和运营过程中，开发无需关心存储层的数据安全、容错、扩容，这些问题全部在云端解决。
（2）不足：Cmem是Key-Value存储，用于应对在线数据的实时高效访问，不具备传统SQL存储的一些常用功能，如实时统计、分析等。但实际上，大部分应用在使用Mysql作为存储层使用的时候，基本上也都是同时只对一条记录进行操作，这正式Key-Value的使用场景。如确实有SQL要求并且数据量适中、性能要求不高的数据，可以使用CDB解决。
第二部分：云存储——数据层解决方案
看过应用开发过程中存储层方案变迁后，回到项目起始阶段，如果在应用开始设计时就考虑使用云存储来解决数据层的问题是非常明智的。一来可以快速开发，使开发者更加聚焦于应用逻辑开发和产品运营；二来减少数据层后期扩容、运维成本，减少故障概率。我们再从各个纬度来全面看下数据层是否使用云存储的优劣。
|
自行设计和解决数据层问题 |
使用Cmem、CDB等云存储方案 |
|
|
开发门槛 |
熟悉LAMP架构和业界知名开源软件如Memcached、Mysql即可
访问www.zzzyk.com 试试 CopyRight © 2022 站长资源库 编程知识问答 zzzyk.com All Rights Reserved
部分文章来自网络， |
