《统一数据服务平台》由会员分享，可在线阅读，更多相关《统一数据服务平台（45页珍藏版）》请在金锄头文库上搜索。
1、统一数据服务平台专用教程统一数据服务平台专用教程中程在线(北京)科技有限公司内部教程 注意保密网站架构发展历程 Perl，CGI,Oracle Java Servlet EJB 去EJB重构（底层 MQ+ESB,数据挖掘,cms） Memcached集群,mysql,数据切分,分布式存储， Hadoop,KV,CDN 安全镜像 敏捷，开放，体验（新一代网站架构的要求)电子商务网站的特点 高并发 数据实时性要求高 数据准确性要求高 大多数页面属于动态网页 网站需要大量的图片展示 用户通过搜索引擎广告类目导航寻找商品 网站读多写少，比例超过10:1 业务量快速增长数据库里的数据数据存在单台数据库中
2、，用户，商品，交易等数 据都在一起，存在许多的关联查询，应用完全耦 合商品商品用户用户评价评价 交易交易收藏收藏连接数问题无论是小型机还是更高端的存储，随着数据的飞 速增长，都带来瓶颈问题。当oracle数据库连接 数达到5000个以后就相当吃力了。数据垂直拆分数据库系统按照不同的业务数据进行一系列垂直 拆分，这种拆分方式具有如下的特点： 1.拆分方式简单，只需要把不同的业务数据进行分离 2.避免了不同的业务数据读写操作时的相互影响 3. 该业务内部及其所导致的问题依旧用户用户商品商品交易交易评价评价垂直拆分问题 当单库iops达到几万次 单库连接数达到几千次 单库每秒SQL执行到几万次 搜索
3、dump数据缓慢，DWETL缓慢 高端存储设备异构的读写分离 写库为集中式的oracle环境，提供数据安全性保障 读库使用mysql，采用数据切分，分库分表，每台mysql放 少量的数据，单个数据分片内部采用mysql复制机制 读库的超大memory容量，起到了很好的cache作用,在内 存中的数据查询性能远远高于在硬盘上的性能 Oracle到多台mysql按规则复制 分区键的选择至关重要，尽量让数据访问落在单台数据库 上 利用好当前的高端硬件，保护好自己的投资构建快速的数据查询应用到DB的数据写入与查询从双向通行变成了单向通行 ，通行效率更高，大大避免了相互影响。“借道”行驶的 情况不再出现
4、水平拆分的问题 对于核心业务，停机时间有限，庞大的数据无法 在短时间内迁移 无法在短时间内完成项目发布过程中的测试工作大数据量核心业务数据迁移的思路 先采用异构的数据库读写分离，将数据复制到目 标Mysql结点上，验证可靠性，机器压力 将写压力从Oracle结点迁移到mysql各结点， oracle停止写对于一些不太核心，业务不太复杂，相关影响点 不多的数据，可以直接进行迁移数据生命周期之历史迁移商品，交易，评价，物流等数据都有自己的生命 周期。通过历史数据迁移，减少在线库的容量， 提高在线库的性能。DataOnLine DataHistroy Data在线与历史应用分离在线库与历史库重要等级
5、不同，在线库更高 同一应用的在线应用与历史应用分离 高级别的应用不能直接依赖于低级别的数据库OnLine ApplicationHistroy ApplicationOnLine Data DataBaseHistroy Data DataBase数据迁移商品访问框架一般商品有几个主要查询 a.主键查询通过分布式数据库，以及分布式缓存系统解决 b.商品管理类查询，这一类查询数据量大，并且还有like查询 的需求，通过实时搜索解决商品商品主键查询主键查询管理类查管理类查 询询分布式数据库分布式数据库分布式缓存分布式缓存实时搜索实时搜索注：考虑不同的读载体的技术实现 性 能和成本用户登录事件数据（
6、日志量90%）与用户主数据（日志量 10%）分离，不仅要分表，而且要放到不的数据库集群中 ，并且做好不同数据等级的容灾处理用户难题 数据库集群自动扩展仍然是个难题，但是是可以 忍受的，底层数据集群经过评估，扩展的频率并 不高 MySql DDL 操作不变，锁表，对写操作影响较大 ，分了比较多的表，进一步加重了维护负担。多种存储方案 不同场景使用不同数据源 关系型数据库 kv 文档数据库 外部数据接口 常见问题1.海量数据面前，用什么策略来保障既能快速响应 用户的请求又能及时应对业务的发展 2.对于后台海量数据的处理如何设计 3.不同区域的数据同步如何处理 4.缓存处理数据架构日益复杂 数据架构
7、现状 数据架构非常复杂在不同场景采用了各种类型的数据源 关系型数据库 搜索引擎，提供商业搜索服务 Cache KV,高性能场景 外部数据接口：如淘宝支付宝 文档数据库 列数据库，后台大规模计算场景 业务模型各个字段分布在不同数埃布据源数据架构日益复杂问题 数据架构复杂，应用需要直接依赖多种类型的数据源 开发人员需要熟悉各种数据源，以及访问方式对开发人员能力提出很高的要求 网站应用组装业务模型的数据查询需要多种数据源带来开发的不敏捷，大量的资源消耗在无意义的模型组装上 网站应用直接依赖于底层数据源，模型发生变更将导致所 有相关应用大面积重构 例如商品模型的图片属性由数据库迁至图片银行 数据源改造
8、也会导致相关应用的大面积重构数据水平切分 跨数据源定位查找问题，实施缓存和性能优化困难新网站架构 敏捷1.业务快速增长，每天都要上线大量小需求 2.应用系统日益膨胀，耦合恶化，架构越来越复杂，会 带来更高的开发成本。如何保持业务开发的敏捷性 开放Facebook和Appstore带来的启示，如何提升网站的开放 性，吸引第三方开发者加入到网站的共建中来 体验网站的并发压力快速增长用户确定体验提出了更高的要 求解决方案统一数据服务平台 在网站应用集群和底层数据源之间，构建一层代理 ，统一数据层 统一数据层的特性模型数据映射实现业务模型各属性与底层不同类型数据源的模型数据映射支持关系数据和非关系型数
9、据库如redis,mongodb 统一的查询和更新API 提供基于业务模型的统一的查询和更新API，简化网站应用跨越不同数据源的 开发模式 性能优化策略字段延迟加载，按需返回设置基于热点缓存平台的二级缓存 异步并行的查询数据 并发保护 过滤高危查询统一数据服务层模型模型字段的数据路 解决思路：半自动化处理。 任何异步并行加载的时机点，全都取决于代码编写 的顺序。 如果有依赖关系的存在，比如例子中的B依赖A的结果，则B 会阻塞等待至A的结果返回，最后A和B的处理就又回归到一个有顺序 序的请求处理。 最后从技术实现上看 从技术实现上说，在调用serviceA获取结果的时，我会直接返回一个 假的LazyLoad产生的mock对象。此时对应的属性值全为null，在你具 体依赖到该modelA的属性数据时，就会有一个阻塞等待，转为 串行的过程。代码实现代码实现对比图很明显，一次很明显，一次request请求总的响请求总的响 应时间就等于最长的依赖关系请求应时间就等于最长的依赖关系请求 链的相应时间链的相应时间异步化，并行化实现类图并发控制，自我保护 并发控制机制:过滤危险ip段 自我保护机制:过滤危险数据请求总结谢谢
