分类目录归档:程序相关

C,Python,环境配置等

数据集合类系统如何架构

数据集合类系统如何架构

以下内容来源于QCon某高可用架构群聊天记录整理

如果携程网想把旅游信息展示到另一平台上 平台和他们的系统数据对接,pull好一些还是post好一些?或者说一个系统只是把好多其他商家的数据集合展示到统一的系统上,这样的系统一般如何架构?

先回答第一个问题:数据对接是pull好一些还是post好一些,这里需要根据实际业务做权衡,如果平台系统很大部分是通过聚合第三方数据再展示,那么比较推荐让第三方post数据,自己设计统一数据规则接口。这种情况,需要考虑自身服务的稳定性了,预防第三方误调用,击垮自身系统。如果只有小部分内容聚合第三方,那就pull,比较好保证自己系统稳定性,不过最终还得把所有的数据转换成自己格式,需要自己开发团队做这块工作。

相比较而言,post时效性高,数据交互少,如果系统会需要各个源的信息,最终也不会只是展示那么简单。如果使用post方案,则需要在接入,数据,读取等方面做隔离,在接入使用mq可以提高吞吐,在读的时候用Cache抗。并且在前期需要考虑好数据存储和数据的量级,因为是第三方的数据,在存储的扩展性方面要有比较好的方案。

最终落地的方案可能是:

按业务隔离,不同的业务相互不影响,拆分子系统;
使用redis和kafka保障高性能,kafka主要一方面用到日志上 一方面用到缓解数据库并发上;
使用nginx和lvs保障高可用;
在后期所有数据进hbase然后用storm做数据流处理和分析

以上这些并不需要一次性做到位,不要过早优化,只需要有一些大的原则,比如隔离,扩展等。小系统会随着业务慢慢演变,最终会变成大系统。在演变的过程中,可能会需要读写分离、业务分布式,分服务,架构就是在这样演变的路上成长起来的。

微信红包实现原理

微信红包实现原理

以下内容来源于QCon某高可用架构群聊天记录整理 背景:有某个朋友咨询微信红包的架构,在官方或非官方同学的解释和讨论中得出以下讨论内容,在此期间有多个同学发红包做现网算法测试。

抢红包过程

当有人在群里发了一个N人的红包,总金额M元,后台大概发生的事情如下:

一、发红包后台操作:

  1. 在数据库中增加一条红包记录,存储到CKV,设置过期时间;
  2. 在Cache(可能是腾讯内部kv数据库,基于内存,有落地,有内核态网络处理模块,以内核模块形式提供服务))中增加一条记录,存储抢红包的人数N

二、抢红包后台操作:

  1. 抢红包分为抢和拆,抢操作在Cache层完成,通过原子减操作进行红包数递减,到0就说明抢光了,最终实际进入后台拆操作的量不大,通过操作的分离将无效请求直接挡在Cache层外面。这里的原子减操作并不是真正意义上的原子减操作,是其Cache层提供的CAS,通过比较版本号不断尝试,存在一定程度上的冲突,冲突的用户会放行,让其进入下一步拆的操作,这也解释了为啥有用户抢到了拆开发现领完了的情况。
  2. 拆红包在数据库完成,通过数据库的事务操作累加已经领取的个数和金额,插入一条领取流水,入账为异步操作,这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额,其金额为1分到剩余平均值2倍之间随机数,一个总金额为M元的红包,最大的红包为 M * 2 /N(且不会超过M),当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备,实际只到8万每秒。

FAQ

  1. 既然在抢的时候有原子减了就不应该出现抢到了拆开没有的情况?
    这里的原子减并不是真正意义上的原子操作,是Cache层提供的CAS,通过比较版本号不断尝试。
  2. cache和db挂了怎么办?
    主备 +对账
  3. 有没有红包个数没了,但余额还有情况?
    没有,程序最后会有一个take all操作以及一个异步对账保障。
  4. 为什么要分离抢和拆?
    总思路是设置多层过滤网,层层筛选,层层减少流量和压力。这个设计最初是因为抢操作是业务层,拆是入账操作,一个操作太重了,而且中断率高。 从接口层面看,第一个接口纯缓存操作,搞压能力强,一个简单查询Cache挡住了绝大部分用户,做了第一道筛选,所以大部分人会看到已经抢完了的提示。
  5. 抢到红包后再发红包或者提现,这里有什么策略吗?
    大额优先入账策略
  6. 有没有从数据上证明每个红包的概率是不是均等?
    不是绝对均等,就是一个简单的拍脑袋算法。
  7. 拍脑袋算法,会不会出现两个最佳?
    会出现金额一样的,但是手气最佳只有一个,先抢到的那个最佳。
  8. 发红包人的钱会不会冻结?
    是直接实时扣掉,不是冻结。
  9. 采用实时算出金额是出于什么考虑?
    实时效率更高,预算才效率低下。预算还要占额外存储。因为红包只占一条记录而且有效期就几天,所以不需要多大空间。就算压力大时,水平扩展机器是。

用户参与记录存储的演变

有这样一个应用场景:用户有两个连续的操作A和操作B,必须是操作A完成后才能执行操作B,如果操作A没有完成就触发了操作B,则显示用户需要先执行操作A,即在操作B执行需要查询操作A是否执行过。这里引申出来的问题是,记录用户参与记录,提供针对用户和操作的查询方法。当不同的数据量时,我们的存储方案会大不相同,随着数据的增长,方案不断演变。

1、数据量较小,用户操作行为固定:
存储:MySQL
方案:我们以UID为key,一行一个用户,每个用户包括的用户作为列存储,比如UID=100,固定存储为操作A和操作B,则表结构大致如下:
table_operation
uid operation_a operation_b
100 1 1

如果我们要查询用户是否参与A或B时,直接使用SQL: SELECT * FROM table_operation WHERE uid=100 AND action_a=1就可以达成目标。

问题:用户操作固定,扩展较难,如果需要增加用户操作行为,则需要增加字段或增加表存储,增加字段的方法在一定的数据量级以下(比如100万)是可行的,如果行为间无关,则增加表存储方案的表现会很不错。

2、数据量较小、用户操作行为不固定:
与场景1相比,当前场景除了uid这个变量,增加了用户操作变量,即我们需要关注用户和用户操作两个变量。
存储:MySQL
方案1:增加操作表,生成操作id,用户操作行为表存储uid和oid。当用户执行一个新的操作时就在操作行为表插入一条记录。其表结构大致如下:

table_operation_info
oid name
1 operation_a
2 operation_b

table_operation
uid oid
1 1
1 2

当需要查询用户1是否执行过操作A时,使用SQL:SELECT * FROM table_operation WHERE oid=1 AND oid=1。
问题:当用户的操作行为较多时,用户操作行为增长速度很快,数据量也为逐渐增大,可能MySQL单表无法负载。解决方案在后续场景中说明。

3、数据量较大,用户行为固定
存储:MySQL
方案:与场景1相比,当前场景不同在于数据量比场景1大,数据量大到MySQL单表负载不过来。此方案解决的就是这个问题,当单表太大时,性价比较高的方法一般是采用分表。我们当前场景的变量是uid,只要依据uid按水平分表即可。

4、数据量较大,用户行为不固定
存储: MySQL
方案1:此方案应用于用户的操作行为可以分类的情况,即在场景1的基础上增加两次分表操作,按操作行为类分表和按用户分表。当前方案中我们需要应对两个变量:操作行为和用户。两次分表分别对应这两个变量,按业务规则做操作行为的分表操作,按用户id水平切分减少数据量。

方案2:此方案是完全的水平分表操作,在场景2的方案基础上,按用户水平切分。

5、数据量超大
存储: MySQL
方案1:分库分表,此时一个库已经无法满足需求,规则依据前面的场景实现,根据实际的需求可以考虑把不同的库放不同的机器上。
方案2:在分库分表的基础上,按位存储,因为一个操作行为有没有执行过是一个是否的状态,即0,1状态,因此我们可以用一个位来存储,64位可以存储64个操作行为的标记。

其它存储
key-value数据库
我们的需求实际上并不需要太多的关系型数据库的功能,简单的 k-v数据库就可以实现我们的功能,并且在性能上也会有所提升,毕竟做得少,会快。
先不管是选择基于内存的,还是非内存的(可以根据实际需求来选择,也可以是热点数据在内存,沉默数据在非内存中),假设我们有足够的空间存储。
方案1:
以uid+oid为key,值可以存储状态,也可以只存储是否参与(0和1),但是会存在key太多的情况,特别是当数据量超大时,uid的个数*oid的个数,可能是你无法相像的量级。
方案2:
一般来说,用户操作行为的数据量完全小于用户的量级,并且用户操作行为的数据可控。如果要减少key的个数,我们可以使用oid+用户分区索引id作为key,这里所谓的用户分区索引是指将用户以某个数量分成一个区,所有的用户都记录在这个这个区间内,比如以10000为一个区间,则uid为1到9999的用户分到区间0,这里可以以1和0存储用户是否执行了此操作,一个key对应的value初始化存储10000个0。当uid=100的用户执行了某操作,则将第100个0置为1。
方案3:
在方案2的基础上,将10000个0转换为10000个01位,假设一个位存储50位,则总共只需要200个。
方案4:
当用户量超大时,大多数的用户对于某个操作可能都是没有参与的,则在方案3的基础上我们增加简单的稀疏矩阵压缩,给每个存储位添加索引,当存储值不为0时才会存储。
方案5:
我还没想到,期待你的分享

小结

  • 随着数据量的增大,总的思路是分冶,当一个表搞不定时分表,当一个库搞不定时分库,当一台机器搞不定时加机器。
  • 对于不同的存储介质选择需要考虑成本和需求,所有的选择都是平衡后的结果。
  • 节省空间,按位存储。
  • 不要过早优化。