50天1个亿,不曾到过的世界-创业半年小结

 

2015年过完年,er又打来了电话,从去年开始,已经是第6次了,包包已经会走了,开始学会通过撒娇、大哭达到自己的目的。和er聊了1个小时,答应晚上和夫人商量一下,心已动摇。这个问题和夫人已讨论多次,还是在犹豫,不知是对未知的恐惧,还是对当下的不舍。

最终决定去上海,和er一起创业。梦想还是要有的,万一实现了呢。

选择离开

”橘子红了,是该摘了。“ -- 《橘子红了》

在腾讯的生活充实,有序,领导重视,同事nice,一切的一切都显示得让人无法离开。

创业是选择要未来,而不是现在--冯仑。

这样的当下,这样的现在,真的舍得?

和leader面谈、和总监面谈、和HR面谈、和GM面谈,惭愧,愧疚,不舍……

一切显示如此匆忙,在腾讯的日子越来越少,看着周围的同事都在忙活,心里不免有一些失落……

离别总是别样的风景,在腾讯的682天,2次晋升、3次发文奖励、1次优秀员工,得到了自己想得到的,遇见了自己该遇见的。在腾大7楼退掉工卡,慢慢走出腾讯大楼,回头看去,有些模糊了。

重新启程

”天青色等烟雨,而我在等你。“——《青花瓷》

3.31号,愚人节的前一天,从上海浦东机场转磁悬浮,5站地铁,到了世纪大道,在2号口见到了依稀有些丰满的er,在网上认识很多年,一直未曾见过面,总算见到活的张er。第一次见面,仿佛现实中认识了很多年,是如此熟悉。

到了办公室,略拥挤,er说已经在张罗新的办公场地了,先将就下,研发部20多人,移动开发,后台、前端、设计、测试。已经是下班时间了,还有一半的人在,有新版本准备上线。

之前已经了解过后端的代码了,对于数据库结构及代码基本已经摸清了,后面就是人员的磨合,对具体业务和流程的熟悉,紧张而忙碌。

一晃一月过去了,经历了几次问题,幸运的是最终都得以妥善解决。在此期间日志系统、监控系统、数据监控系统等周边系统逐步上线,一切朝着稳定的方向前进。

新的挑战

”谁的江山,马蹄声狂乱,我一身的戎装,呼啸沧桑“——《菊花台》

搬到新的办公场地,还没有装修好,一切从简。

面对着黄浦江,看着江上船来船往。

有一天,er忽然抬头笑道:你看,这江边有很多树啊

我道:嗯。 

er道:你可知道有多少棵 

我道:三十七棵。 

er的心沉落了下去,笑容也冻结。 

因为他数过江边的树。他了解一个人在数树时,那是多么寂寞。

4月25日,火理财项目正式启动,第4天后台所有接口ready,第8天,iOS版本出企业版,第10天,安卓版上线,创业的速度,创业的激情,狼性的团队,已不再是寂寞。

内测版通过,公测版通过,5月正式上线。

不曾到过的世界

“有的人求名,有的人求利,我求的是什么呢?”  -——《陆小凤传奇》

第1期,1万

第2期,50万 144小时

第3期,100万 14小时

第4期,100万 10小时

……

……

第65期,700万 12小时

到第40期,项目投资总额就已经超过了1个亿。

见或不见,一个亿就在那里,不悲不喜

念或不念,一天700万就在那里,只增不减

跟或不跟,各种问题就在那里,不增只减

这样的一个世界,光怪陆离,不曾到过,曾想过,只是没想过会来得这么快。

手机24小时开机,电脑24小时在身边,快速处理所有发生的问题,我们做的是金融,过手的都是钱,不能有个万一,兢兢业业,诚惶诚恐。

新版快速迭代,两周一个版本,每天后端都有迭代发布,新的规划正在实现,如此滚动……

后记一 关于技术

  • 当业务需要时,使用数据库的最高级别的事务机制保证数据的完整性;
  • 在数据库层面制定好数据约束,即使代码出错最终也不会影响数据;
  • 用户的操作最好在数据中体现出来,确保数据的完整性,关键性操作数据需要有日志类结构存在
  • 如果有第三方接口、服务或数据,在离这些接口、服务最近的地方我们需要有一个完整的日志,忠实于数据的出和入。
  • 初期个人分支开发,主干发布,中后期版本分支开发,主干发布,确保主干的持续可用。
  • 如果可以用人肉临时去解决,而技术要花比较大的成本或难度,那么直接用人去解决吧。
  • 在做方案时需要考虑数据的可追溯,特别是重要数据,简单一点留个操作日志,复杂一些,从数据结构上保证数据的可追溯。

后记二 关于管理

  • 不认同,但是执行
  • 我们要依次管理好人、产品(包括技术)和利润
  • 项目管理方式得看人,员工能力不足管理跟上,员工能力足够可以粗放管理
  • 打工要nice,创业要狼性,一团和气,必然低效
  • 当团队成员能力不齐,有高有低时,需要采用不同的管理方式,对于水平高的要多放手,少跟进,关注结果,对于水平不高的,要排期到天,多跟进。
  • 创业时需要考虑人力成本,以及人的投入产生比,重要的人做重要的事情,让其发挥其应有的价值,不合适的人要早点淘汰。
  • 管理者的分工是让大家更好,更流畅的协同工作,向同一个目标前进。团队成员可以个性鲜明,但是不能让大多数人迁就极个别的人。
  • 上层看问题,下层做事情
  • 管理者的工作:收集信息,决策

最后 招聘

开发经理

我们希望你是:

  • 能cover住20人+的团队的能力,不仅仅是某种技术
  • 能cover住每天上千万的资金流
  • 能够把握住项目的节奏,对项目结果负责

除了开发经理,我们还需要更多的PHP、安卓、iOS、前端、UI、Java、测试。欢迎推荐和自荐,base in 上海。

我的QQ:81894135

数据集合类系统如何架构

数据集合类系统如何架构

以下内容来源于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. 采用实时算出金额是出于什么考虑?
    实时效率更高,预算才效率低下。预算还要占额外存储。因为红包只占一条记录而且有效期就几天,所以不需要多大空间。就算压力大时,水平扩展机器是。