20170705-消息系统选型等

Posted by PaymentGroup on July 5, 2017

主题一: 消息传输系统

Q1:请问一下,目前有没有支付系统把kafka作为可靠消息传输系统,主要场景有哪些,而不仅仅作为日志系统消息收集使用而已,谢谢
A1: 用rabbitmq吧,稳定性非常好
A2:看消息量,大部分情况下activemq, rabbitmq是足够了。Kafka的问题是部分消息会重复发送,而且kafka没有事务。
A3:我感觉ACTIVEmq就很好用
A4:每天百万以内的消息activemq够用的了。仅消息来说是足够了,但对于电商+支付来说,经常会需要扩展。比如可靠消息,延迟通知, 失败重试、安全机制等,都需要对消息系统进行扩赞。我们是在activemq上做扩展的。

Q2:kafka与rabbitmq的区别体现在哪里?
A1:kafka没有用过,专门用于处理日志。rabbitmq原本就是处理金融方面的业务。
A2:rabbitMq和amq两套不同的标准,一个是amqp协议,另一个是基于jms标准实现的
A3:rabbitmq 功能全,慢; zeromq是功能少,快;activemq介于两者之间。
A4:以前没用过任何mq的话,先玩activemq吧,易安装,易维护,容易踩坑也容易填
A5:我打算采用kafka的mirror功能做灾备

Q3:kafka做双机房,你们切换怎么做的?
A1:

主题二: IVR语言支付

Q1:群里谁家做了IVR语言支付,你们用的哪家通道?
A1:广州易联支付

主题三:聚合支付SDK和商户APP的交互

Q1:请教个问题 聚合支付公司的SDK、商户的APP跟聚合支付公司是怎么交互的?
A1:商户APP通过聚合支付SDK唤起第三方支付控件(APP),下单动作由商户APP –> 商户服务端 –> 聚合支付服务端 –> 第三方
先下单,再支付
结果分两种方式拿到,同步:支付控件 –> 聚合支付SDK –> 商户APP,异步:第三方 –> 聚合支付 –> 商户
聚合支付也有消息通知机制给商户,也有开放查询接口

Q2:支付过程是分两步吗?1 先下单获取参数 2用参数调用SDK唤起第三方控件?
A1:是的
Q3:为啥不一步完成呢?我说的是商户端:商户端直接调用SDK, SDK去聚合支付那里获取参数,不透传给商户,直接用参数唤起第三方控件
A1:安全。商户和聚合支付之间通信都有加密机制,密钥放在商户服务端安全些

主题四:商户交易数据的统计

Q1:商户交易数据的统计功能一般放在哪个系统做?账务系统?还是专门的统计系统?
A1:报表系统

主题五:支付宝退款期限

Q1:支付宝原路退回的支付订单有时效限制么?我知道微信是一年之内的
A1:支付宝有开放平台 图2017-07-05 11:19:32

Q2:再问一下 有没有像咱这样 弄出一个两年之内都能退款的优惠?这样如果时间足够长,是不是只能走银行转账了?
A1:1,2年内都可以退款。自己垫就行了,转账代付什么都可以。
A2:银行的退款也有周期限制吧,我记得我们接的招行就是只能一年,超过一年退不回去,只能走代付
A3:一般没有提供两年,这么久的吧,一般没有提供两年,这么久的吧

主题六:限额模块

Q1:大家一般是把限额模块放在业务系统还是风控系统呢?
A1:初期都没所谓。但是我觉得理论上还是放在风控系统里好。

Q2:如果风控系统挂掉了,那限额检查如何处理呢?是否业务系统要做限额备份呢?
A1:简单处理办法是,风控挂了,别交易了。
A2:主要是在风控系统这边,我们是风控挂了就不交易了。风控系统有可能受到有目标的攻击而趴窝。 对风控系统来说,需要保证可靠性,除了分布式部署外,还得有降级方案,来保证风控系统可靠运行。
A3:风控挂了,直接放交易。主要还是看公司的决定,都可以选择。这个每家对风控的承受能力不一样,各自决策。
A4:直接放交易不是有效的办法,但是直接停止交易又是很大的损失,这是利益和弊端的一个权衡
A5:可以按风险影响大小,将风险分级,小的可以过,大的拒掉。理论上就像群主说的,风控系统要稳定,具有容灾容错能力,如果技术上没有这个实力,风险分级就是一个办法。因为任何交易系统其实还是要以交易履约为原则的,尽量让交易做成。

主题七:境外购物

Q1:群里有人在境外购物网站上购物过的吗?用的什么支付?
A1:Paypal。pay在国外一般放在很显眼的位置

主题八:信贷风控

Q1:请教下各位技术大牛 P2P 信贷 风控建模是怎么做的,主要用到什么模型,什么技术?
A1:http://wechat.lixf.cn/2017/06/16/wechat30/
A2:信贷风控从流程上讲有贷前、贷中、贷后控制,从风险上分为欺诈、信用评级、收益比,从模型上讲为规则、模型、神经网络,从计算上分在线、近线、离线。核心的东西,就是所谓的数据,客户画像、行为画像等,再加上一些黑名单、关系图谱、指标运算等,系统架构上,与推荐系统有相同之处,可以借鉴。
图:2017-07-05 16:13:57

Q2:信贷风控使用分析数据通常使用:SPSS、SAS,采集的数据源和输出的数据集 有api 和mysql交互吗?
A1:这些都是公开的,主要靠数据支撑 图2017-07-05 16:18:18

Q3:关系图谱,反欺诈是看关系圈的信用贷款情况吗?
A1:算法没有啥高深的,关系图谱主要是防团伙欺诈
Q4:强联通 弱联通 够用吗?需要也用什么核序列坍缩算法那种求社群吗?
A1:关系图谱圈子多大,取决于数据的广度

Q5: 有个问题,我用交易圈的数据 (发生交易就产生关系) 用了弱联通分割后有些全还是很巨大(最大那个有100万人),以啥维度或者算法进行进一步分割比较有解释性呀?
A1: 弱联通问题不大,如果想进一步分割 ,需要找出强变量来. 比如一个商户,肯定会有很多人跟他有交易. 如果不想要这些关系,可以采用白名单机制给屏蔽了。把资质好的商户加入白名单,关系就不用画了。你也可以只将大额交易、高频交易、等额交易的关系画出来,这些是比较可疑的

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。