外贸假发网站,怎样给公司做网站,wordpress 乱版,品质好的办公室装修设计(本文适于使用Aaf框架的开发者阅读) 1. 基本原理 在Aaf框架中#xff0c;“对象”和“存储”的关系映射有一个关键的纽带StorageAlias#xff0c;即“存储别名”#xff0c;同样一个类型#xff0c;在不同的存储别名下#xff0c;可以自由映射到任意存储“位置”。 “位… (本文适于使用Aaf框架的开发者阅读) 1. 基本原理 在Aaf框架中“对象”和“存储”的关系映射有一个关键的纽带StorageAlias即“存储别名”同样一个类型在不同的存储别名下可以自由映射到任意存储“位置”。 “位置”有两个元素决定一个是存储上下文StoargeContext另外一个是数据表名TableName。缺省的StorageContext在Persistence.Config中配置缺省的数据表名就是类的名称。 所有的映射关系存储在两个地方一个地方是TypeDescription的ExtendedAttributes属性中这里存储的映射主要来源于 配置文件Persistence.Config中的配置。关系的建立是在Aaf启动阶段由PersistenceMappingService初始化完 成调用StorageContextMappingService中的GetStorageAliases方法取得 Persistence.Config中的存储别名的配置信息。此外默认的存储上下文和默认的表名也初始在此扩展特性中。 通过Persistence.Config方式配置的映射是“相对稳定”的映射数量也在一个非常有限的级别上例如我们可以将订单信息按照 交易类型的不同存储到不同的数据库上也可以将交易完毕的订单信息搬迁到历史库上我们就可以定义出来形如 “EscortOrderByHistory”这样的存储别名一看就知道是“担保交易的历史交易数据”。 另外一个存储映射关系的地方是存储别名信息助手StorageAliasesInfoAssistant助手的映射关系有三个来源IStorageAliasTeller提供、手动动态添加、数据库参数配置。 通过IStorageAliasTeller方式我们可以根据系统要求动态 的解析一个存储别名不仅如此我们还可以根据AgileObject.Id自定义规则推导出其对应的存储别名例如我们可以将用户按照一定规则分表存 储然后在用户的Id中包含存储别名的信息这样我们就可以非常方便的将海量用户拆分到若干分表当中实现数据的分表存储。此外与IDataRadiationClassifier搭 配起来还可以实现“多维存储” 就是将同样一份数据按照不同的应用需要散射到多个存储位置有可能是散射到不同的数据库上例如商品信息散射出一个专门供查询的库上也有可能是同一 数据库的不同表上例如订单信息根据买卖不同散射到特定的数据表上。同时自动维护各个数据库上数据的一致性。这样就可以分身有术让多个的数据库分担 查询压力。 手动动态添加是通过IStorageAliasesInfoAssistant的RegisterDynamicStorageAlias方法将已知存储位置添加到映射表中同时返回一个GUID码作为存储别名。 数据库参数配置这种情形是存储映射信息是以参数的形式存储在数据库中的 在Aaf.ParaService加载过程中会自动生成一个Aaf.StorageAliases的配置节点节点路径是Aaf.StorageAliases/[StorageAlias](存储别名可配多个)节点配置格式是:[ StorageContext1,TableName1 \n AppId1: StorageContext2,TableName2 \n AppId2: StorageContext3,TableName3 \n ] 其特别的地方是在分布式环境中根据AppID的不同将数据持久化到特定的存储上。 2. 应用实例 在5173系统中有许多应用尤其以用户、发布单、订单及资金明细比较典型。下面我们一起去看看。 2.1. 用户数据分拆 用户数据是基础数据而且是一种会持续增长的基础数据这种数据的膨胀会让其性能表现越来越差因为是基础数据又不能删除或者搬移我们处理这种数据的基本策略是将所有用户按照一定的策略散射到多个数据表中以缓解单表的压力下面我们分析一下实现过程 1、 将所有用户数据按照注册日期段分组每一个分组共用一个独立的数据表分拆存储分拆策略启用有一个时间基线之前的数据依然存储在UserInfo中 自此时间基线之后的数据便存储在形如UserInfo_X的数据表中。例如设立时间基线为2009-5-22每隔90天建立一个新组某用户注册时间 为2009-12-2号与时间基线相差194 天除以90得2存储在UserInfo_2中。 2、 创建一个类UserInfoSaTeller实现IStorageAliasTeller接口 3、 将UserInfoSaTeller注册到别名信息助手注册方法如下 PersistenceMappingService.StorageAliasesInfoAssistant.RegisterTeller(typeof(User), new UserInfoSaTeller())这个注册在UserService的Run方法中。 4、 保存新用户时内核将调用UserInfoSaTeller的GetPrimarySaveStorageAlias方法取得存储别名传入参数是灵便对象的Id号因此我们需要构建一个含有分表特征信息的Id我们现用的Id为“US09120282660351-00F7”其中红色加粗部分为注册日期通过注册日期我们可以计算出一个特定的存储别名UserInfo$2 内核将继续调用UserInfoSaTeller的GetTableName传入参数就是GetPrimarySaveStorageAlias计算出 来的“UserInfo$2”很显然我们轻易可以得出实际的存储表名“UserInfo_2”。可见我们只要按照规则构造好用户的Id程序便可以自 动识别出来应该放到哪里存储。 5、 根据Id号取用户实例的过程与保存过程基本类似内核调用UserInfoSaTeller的GetPrimaryLoadStorageAliases方法取得加载时存储别名之后的映射关系与对象创建时相同。对于用户数据保存和获取时的存储别名是一致的。 6、 登陆时怎么办登陆使用的用户名进行登陆而不是用户Id。没什么太好的办法基本思路还是遍历所有分表好在我们的分表时间区间都是以月为单位十年 下来也不过一百多个表。此外当一次遍历完成之后我们可以将此用户对应的存储别名状态记录在某个地方例如Cookie中这样减少遍历的频度。 2.2. 发布单数据分拆 发布单数据的拆分策略稍微复杂一点。根据实际应用需要除了发布单默认的存储位置之外发布单还有几种存储形态根据用户分组、根据游戏、交易 完成的历史数据。根据用户分组分拆是指把所有用户在逻辑上分成若干个用户组每个用户组共用一个存储表根据游戏更容易理解即每一款游戏共用一个存储 表交易完成的历史数据就是那些单子不会再发生变化这种数据主要通过数据库Job定期搬移的。与用户数据分拆不同的是发布单是一份数据在不同的地 方用不同的策略存储即多维存储游戏维度、用户分组维度。下面我们分析一下数据创建和加载的过程 1、 先看创建过程。因为是多维存储BizOffer需要实现IDataRadiationClassifier接口Aaf内核在工作时将调用其中的GetDataRadiationClasses方法来获取每个维度的维度标识。 2、 使用维度标识调用IStorageAliasTeller的GetDimensionStorageAlias方法翻译出维度对应的存储别名形如Search$0043和BizOfferBy023F-Escort加黑的分别是“游戏标识”和“用户逻辑分组标识”。 3、 解释下用户逻辑分组的来历我们将用户分成1000个逻辑小组分组的方法依然与注册时间、时间基线相关用两个时间的差天数对1000取模这样就 会得到一组数字将这组数字用四位16进制格式化就是散射用户的逻辑分组标记这个标记我们也在用户Id中记录了“US09120282660351-00F7”即蓝色加粗部分。当一个用户创建发布单的时候我们便知道其逻辑分组为00F7。游戏标识要简单一些每一款游戏都会有一个自增长的表号此表号也是用四位16进制表示。注意用户分组目前是固定为1000个组的而游戏分组是不断增长的。 4、 接下来就是分别对每个维度的存储别名进行存储动作通过IStorageAliasTeller的GetContextName和GetTableName取得实际的存储位置信息。 两个维度路径是 存储别名–存储上下文名称–数据库名称–数据表名 游戏散射Search$0043– RadiationOffer1– SearchOffer– BizOfferby0043 用户散射BizOfferBy023F-Escort–OfferDataRadiations–OfferDR–BizOfferBy023F 5、 还有一个维度是历史库的发布单数据这个是Job搬迁创造的数据表的命名规则是一个月三张表按旬存储形如BizOfferby200607_1。虽然创建过程不是Aaf做的但查询数据时是Aaf做的后面我们在做查询分析的时候要考虑这部分数据。 6、 在单条数据加载的时候重点是确定查询策略了就是什么数据该先从哪个维度去找策略确定之后就是拼存储别名来定位查询的数据库表了。我们现在的查询策 略是先查找当前库拼EscortByCurrent的存储别名此存储别名在Persistence.Config中配置了映射关系接着检查“用户分 组维度”再接着查找历史库。 几个查询路径如下 当前库EscortByCurrent–ConsignmentByCurrent–Consignment–BizOffer 用户散射BizOfferBy023F-Escort–OfferDataRadiations–OfferDR–BizOfferBy023F 按发布单结束时间历史库后台使用Escort|200912_1–OfferHistory–OfferHistory– BizOfferby200912_1 按发布单创建时间历史库(前台使用)Escort~200912_1– OfferHistorybyCreatedDate– OfferHistorybyCreatedDate– BizOfferby200912_1 7、 接下来我们梳理一下各种发布单列表是怎么出来的当一个查询过来的时候我们首先判断查询条件中是否含有用户信息如果有直接走“用户分组维度”。如果 没有用户信息至少会包含一个游戏信息即GameId走游戏维度的存储。注意列表查询没有走“默认维度”这样默认维度就可以专心用于交易了。 8、 8、 有关发布单查询还没有结束。就是另有一个发布单搜索对象BizOfferSearch这个是另外生成的一份数据专门供搜索用与当前交易平台隔离。同样也有两个维度 存储别名–存储上下文名称–数据库名称–数据表名 游戏散射Search$0043– RadiationOffer1– SearchOffer– BizOfferSearchby0043 用户散射BizOfferSearchBy023F-Escort–OfferDataRadiations–OfferDR–BizOfferSearchBy023F 2.3. 订单数据分拆 订单的数据分拆方法类似根据实际应用需要除默认存储外也有几个维度的存储买家分组散射、卖家分组散射、历史库数据。从技术实现方式来讲完全一个套路。。 1、 订单创建过程与发布单雷同不再赘述。需要注意的是买卖维度的数据表名中也是附加了用户分组标识。一笔订单会因为买家和卖家的分组不同而存在于不同标识的分表中。 2、 订单取得过程先从默认库查找找不到再去买家维度找找不到再去卖家维度找还找不到就到历史库中找。 维度路径是 存储别名–存储上下文名称–数据库名称–数据表名 买家散射OrderByBuyer023F-Escort– OrderDataRadiations– OrderDR – OrderByBuyer023F 卖家散射OrderBySeller009B-Escort– OrderDataRadiations–OrderDR– OrderBySeller0339 历史库Escort|200912_1–OrderHistory–OrderHistory– Orderby200912_1 3、 在前台列表查询中买卖双方呈现自己的订单时是分别从买卖维度即OrderDR这个库中取数据的。后台列表查询走的是默认维度的订单库。同时对于交易完成的数据到历史库OrderHistory中查询。 2.4. 资金分表 AccountDetail除默认在外还有用户分组维度、历史库维度。 1、 多维存储路径 存储别名–存储上下文名称–数据库名称–数据表名 用户散射AccountDetailBy00F7–DataRadiations–BkDR– AccountDetailBy00F7 历史库200912_1–BkHistory– BkHistory– AccountDetailBy200912_1 2、 特别要说明的是每种资金类型都有自己的独立的类他们如何共用AccountDetail这样一个存储的呢原来所有的独立的资金类型都派生自 AccountDetail而AccountDetail中设置的“[AgileObjectStorage(TableName AccountDetail, ContextNameBkUser)]”也被继承下来了。其实更重要的是它们也继承了的IDataRadiationClassifier实 现此外在PaymentService的Run方法中几乎所有类型都注册了AccountDetailSaTeller于是实现了所有类型的存储 规则统一。 2.5. 映射列表 以下是开发环境中的映射关系列表 对于这些类型如果要修改字段每一个关联维度上对应的分表都要变更我们经常碰到的缺字段就是某个维度上有缺失。 类型 数据库名 数据表名 存储上下文名 存储别名 UserBkUser(默认主库)UserInfo_1UserInfo_2… UserInfo_n BkUserUserInfo$1UserInfo$2… UserInfo$n BizOfferConsignment(默认主库)BizOfferConsignmentByCurrentEscortByCurrentSearchOffer(游戏散射)BizOfferby0000…BizOfferBy07D0…RadiationOffer1Search$0000…Search$07D0…OfferDR(用户散射)BizOfferBy0000…BizOfferBy03E8OfferDataRadiationsBizOfferBy0000-Escort…BizOffeBy03E8-EscortOfferHistory(历史库By交易完成时间)…BizOfferby200912_1BizOfferby200912_2BizOfferby200912_3…OfferHistory…Escort|200912_1Escort|200912_2Escort|200912_3…OfferHistorybyCreatedDate(历史库By创建时间)…BizOfferby200911_1BizOfferby200911_2BizOfferby200911_3…OfferHistorybyCreatedDate…Escort~200911_1Escort~200911_2Escort~200911_3…BizOfferSearchConsignment(默认主库)BizOfferSearchConsignmentByCurrentEscortByCurrentSearchOffer(游戏散射)BizOfferSearchby0000…BizOfferSearchBy07D0…RadiationOffer1Search$0000…Search$07D0…OfferDR(用户散射)BizOfferSearchBy0000…BizOfferSearchBy03E8OfferDataRadiationsBizOfferSearchBy0000-Escort…BizOfferSearchBy03E8-EscortOrderConsignment(默认主库)OrderConsignmentByCurrentEscortByCurrentOrderDR(买家散射)OrderByBuyer0000…OrderByBuyer03E8OrderDataRadiationsOrderByBuyer0000-Escort…OrderByBuyer03E8-EscortOrderDR(卖家散射)OrderBySeller0000…OrderBySeller03E8OrderDataRadiationsOrderBySeller0000-Escort…OrderBySeller03E8-EscortOrderHistory(历史库)…Orderby200912_1Orderby200912_2Orderby200912_3…OrderHistory…Escort|200912_1Escort|200912_2Escort|200912_3…AccountDetailBkUser(默认主库)AccountDetailBkUserCurrentBkDR(用户散射)AccountDetailBy0000…AccountDetailBy03E8DataRadiationsAccountDetailBy0000…AccountDetailBy03E8BkHistory(历史库)...AccountDetailBy200912_1AccountDetailBy200912_2AccountDetailBy200912_3…BkHistory…200912_1200912_2200912_3…说明 Escort是交易类型此处只是举例应用中可能是其它标识。 除了上面的映射自定义映射还有一些顺着IstorageAliasTeller的实现类去寻找吧。 转载于:https://www.cnblogs.com/hb_cattle/articles/2029325.html
