1)自我介绍
2)项目介绍
3)VPI会员卡是在什么时候生成,如果会员过期怎么处理?
VIP会员的生成是当用户首次注册账号成功后,然后我们采用唯一标识生成算法,比如说UUID或Snowflake算法,确保每个会员身份标识的唯一性;同时在数据库中添加储存会员身份标识和会员到期时间。然后采用xxljob设定一个定时任务,定期检查会员是否到期,如果会员服务到期了的话,就使用WebSocket向会员过期的用户发送通知提醒用户。
4)项目中的医生是如何进行排行的?
给医生数据添加竞价属性:在医生数据中添加一个竞价字段,表示医生的竞价排名权重。可以根据医生的竞价金额或其他相关因素来确定竞价权重。
构建查询请求:使用Elasticsearch的Java API构建查询请求,按照竞价权重进行排序,以获取竞价排名较高的医生。
发送查询请求:使用Elasticsearch的Java API将查询请求发送给Elasticsearch集群,并获取查询结果。
处理查询结果:根据返回的查询结果进行处理,提取竞价排名较高的医生数据,并返回给用户。
5)怎么实现附近医生展示
为了实现附近医生展示,我们将所有注册签约以及公开信息的医生的信息,包括专业方向,id,图片,所处医院,职位等,最重要的是办公地址经纬度存入到ElasticSearch索引表中设置为GEO point类型。
然后获取用户当前的位置的经纬度,然后使用ElasticSearch的GEO方法查询当前位置指定半径内的医生文档信息,返回到前端页面,还可以在查询时进行条件查询过滤,用户可以查询指定专业方向的医生,快速定位到需要的医生
6)为什么使用Websocket作为在线客服聊天?
因为WebSocket是一个基于TCP/IP协议的长连接通信协议,具有实时性,这就表示可以使用它作为即时消息推送的技术。而且WebSocket可以解决大规模并发问题,因为WebSocket使用的是单一的TCP连接,相对于HTTP来说,减少了网络传输的开销和额外管理开销,可以减轻服务器的负载,提高性能和吞吐量。它还具备检测恢复异常连接状态的功能,可靠性和稳定性比较高,以上就是我们选择WebSocket作为在线实时聊天技术的原因。
7)静态页面的好处是什么?
静态页面的好处可以从三个方面来说,首先静态页面加载时,不会走数据库,可以减少数据库的压力,同时可以避免与服务器进行交互,减少了潜在的安全风险。
第二点,存储方便,静态页面可以直接通过文件传输方式部署到服务器。
第三,静态页面易于缓存,可以通过缓存服务器或内容分发网络(CDN)来提供更好的性能和用户体验。
8)在什么场景下采用静态页面?
当我们的页面内容不需要频繁的修改或者更新时,可以设置静态页,比如我们新闻热点资讯等,文章一旦成功发布,几乎不会再次进行修改。
还有就是,我们的页面需要处理大量并发请求的场景,比如商品页面等,使用静态页面 可以提高响应速度。
9)你们在采用静态页面时有没有做过具体的优化?
1.模板生成技术复杂度
2.存储问题
3.写入磁盘io性能问题
关于前2个问题,可以利用igemontior直接进行页面管理(秒杀项目第一章)实现全量静态化,增量静态化,模块集中管理,多模式存储
关于io性能,可以利用多线程completetableFuture结合xxl-job任务分片集群任务进行处理。
10)请说说微信支付的具体流程?
我就具体在小程序预约支付这块讲讲具体的一个微信支付流程,首先我们用户会再医生预约这块点击预约,那么我们的用户端会将当前用户的信息进行一个审核校验,如果审核校验通过我们会再订单管理这块创建一个预约单,那么会将预约单中的预约号和一些主要的信息发送给微信支付,微信支付系统会自动生成一个预支付单发送给订单管理这块进行一个判断,如果接收到预支付单标识位,那么开始生成代签名的支付信息,返回给用户端,那么会吊起微信支付,向微信支付系统鉴权调起支付,微信支付系统验证授权权限是否正确,如果正确返回给用户端进行一个支付界面的展示。如果用户确认支付输入密码后,会提交授权信息给微信支付系统验证当前的一个支付的授权是否正确,异步通知平台支付结果是否正确,并且支付管理保存支付通知,向微信支付系统返回成功处理信息,由微信支付将支付结果返回给订单管理,并将预约单状态进行更改,用户小程序通过支付状态查询用户端,用户端发送查询接口获取微信支付的支付结果这是给用户。
11)你在附近医生这块采用ES的好处是什么?
ES是一个分布式、高性能的搜索引擎和分析引擎,它具有并行处理和水平扩展的能力。
能够处理海量数据,并提供快速的搜索、聚合和分析功能,适用于大规模和高并发的应用场景。
同时还能满足实时数据处理,还支持数据的分片和复制,确保数据的持久性和可靠性
12)你们项目的开发流程是什么?
我们项目采用前后端分离的模式开发。
在项目启动后,由产品经理用了大概一周时间设计了第一版的产品原型,召开两次需求评审会来确定最终的需求。
接下来设计组开始进行效果图设计,开发组进行技术研讨会确定技术选型,并确定接口文档,与前端人员确认。接口确认好,前端就按照效果图、接口文档进行前端代码的开发,而后端就按照产品原型、接口文档进行后端代码的开发。前后端开发完成后,前端和后端进行前后端联调。最后测试、上线部署。
13)在静态页面这块,你们采用了Aliyun OSS进行静态页面的存储,为什么呢?
因为Aliyun OSS 提供高可靠性和高可扩展性的云存储服务。它可以自动处理数据冗余和备份,并具有弹性的存储容量,根据需要进行动态扩展。
并且Aliyun OSS 在全球分布式网络中拥有多个数据中心,所以用户可以从最接近他们所在地区的节点快速访问静态页面。
它还提供多层次的数据安全保护措施,包括数据加密、访问权限控制和防恶意攻击等。通过配置适当的权限策略,可以确保只有授权用户能够访问静态页面。
14)为什么采用ES中的GEO作为显示医生位置?
使用ES的GEO功能可以查询与指定位置相关的数据,例如在某个范围内的地点、附近的地点等。这对于基于地理位置的应用非常有用,如该项目中的附近搜索。
还可以对搜索结果进行地理距离排序,即我们可以按照与指定位置的距离对查询结果进行排序,从而获得最近给定位置的结果。它还可以将地理数据可视化,以便更好地理解和展示数据。
15)如何解决医护人员的入驻问题?
(其实我不了解这个入驻问题,因为我的项目没有,我也不知道谁写的这个入驻,我就依照我的理解去说)
首先就是业务逻辑上的:
一个医生想要,入驻某个软件(医疗软件),做一个网上的医生,或者是入驻某个医院(医院管理系统),那么就是首先要对其进行审核,审核他的资质,执业证书什么的,这个大概率应该是通过人工审核吧?应该是没有相关的自动审核,写这个的同学可以自己搜一下,审核通过后,对其信息进行存储,(如果是医院管理系统还要对其进行一个归属,归属到那个科室之类的)这就实现了医护人员的入驻。
稿子上:
医生入驻,首先需要提交身份信息,相关证件,这些数据存放到数据库中,状态为未审核,后台管理人员会对其进行审核,审核通过以后,将其数据存放到医生表中,如果为通过审核,那么还是存放到原来的数据表中,将状态该为未通过。
16)说说ES中的GEO需要哪几个参数(说出英文名,并且含义是什么)?
es中的GEO需要四个参数,分别是 fieId(字段名称),lat(纬度),lon(经度),distance(距离)四个参数分别代表着
包含地理位置信息的字段名称,地理位置的纬度值,地理位置的经度值,以及给定搜索结果距离给出的最大距离,可以用各种单位进行指定
17)ES在什么场景下使用?
既然问的是es在什么场景下使用,那我们就要明白,什么是es,很多人都会把他当成一个搜索引擎,但实际上她是一个NoSql数据库,里面有强大的搜索引擎,所以我们可能会使用到es
在这个项目中,什么场景需要用到呢,首先就是搜索药物,药物太多了,如果用mysql的正向索引的话,那太慢了,所以使用es,他的倒排索引,非常适合这种大规模量的搜索,其次就是搜索订单,不管是进货订单,还是患者订单,都是一个庞大的数据,这个时候使用es搜索,就非常巴适。更多的东西我就不一一举例。
既然说es,那就要明白,为什么使用es可以增加索引效率,那就要说他的倒排索引了,倒排索引就是每个词项建立一个列表,这个列表包含了这个词项的所有文档的引用或指针,还有一个文档列表,里面存放了每个文档中包含的词项的引用或指针。在搜索的时候,系统就会根据用户提供的关键词,查找对应的词项列表,在根据这个表快速确定改关键字的文档指针或引用,在找到相关文档。
你甚至还可以讲述一下es是怎么出现的,你肯定不知道这个的最初创建是因为一个程序员看他妻子查找菜谱速度太慢而创建出来的,无意之举,却创造了这么大的价值,几十亿美元额的融资。
我上述说这些东西,其实和这个题越跑越偏,但是我为什么要这么写呢,就是告诉你们,并不是知道这个技术点叫什么就可以了,你还要知道为什么使用它,因为他的某些功能强大,所以我在选择的时候使用它,而你在讲述他的产生,更能体现你对于技术方面很感兴趣,喜欢研究新鲜的,特别的东西。
18)支付涉及到哪些加密算法?介绍一下RSA、AES算法
这个题目没有办法口语化,这个需要你们自己去进行自我理解,自己总结,如果我进行口语化的话,那是我的理解,可能会让你们理解起来有所偏差)
RSA、AES、HMAC
RSA(Rivest-Shamir-Adleman)算法:
RSA是一种非对称加密算法,它基于使用公钥加密和私钥解密的原理。在支付中,RSA常用于确保安全通信和数字签名验证。与其他对称加密算法相比,RSA更适合用于密钥交换和数字签名,而不是用于加密大量数据。RSA算法的安全性基于大数的因子分解问题,这意味着破解RSA算法需要巨大的计算能力。
AES(Advanced Encryption Standard)算法:
AES是一种对称加密算法,它被广泛用于支付系统中的数据加密。AES使用相同的密钥加密和解密数据,因此速度比非对称加密算法快。AES被认为是目前最安全和最常用的对称加密算法之一。它提供了多种密钥长度的选项,例如128位、192位和256位。
HMAC(Hash-based Message Authentication Code)算法:
HMAC算法是一种基于哈希函数实现的消息认证码算法。它用于验证支付请求的完整性和真实性,以防止篡改和伪造。HMAC算法结合了密钥和哈希函数,生成一个固定长度的认证码,用于验证消息的完整性。
19)哪里用到了数据同步?怎么实现?
我们这个医疗系统中用户端的搜索机构/医生、查看医生信息、机构信息详情这些都使用到了数据同步。实现思路是使用消息中间kafka来实现,具体的流程是在该项目的管理端添加医生或者修改医生信息以及生成静态页的时候向kafka指定的主题中发送消息,用户端用来监听指定主题的消息,解析出消息的数据,将这些数据再同步到ES的索引库中。
20)为什么采用Xxl-job?
我们这个医疗项目在开发订单模块的功能时考虑到会使用到定时任务的技术,所以在起初关于定数任务框架的技术选型中有做讨论,开始选择的是Spring传统的定时任务@Scheduled,但是该技术存在一些问题,比如做集群任务的重复执行问题,cron表达式定义在代码中,修改不方便,定时任务失败了,无法重试也没有统计,如果任务量过大,不能有效的分片执行。所以我们考虑到了分布式任务调度框架,比如 TBSchedule、xxl-job、Elastic-job经过讨论选用了学习简单、轻量级、易扩展的xxl-job,该框架简单灵活、丰富的任务管理功能、高性能、高可用、易于监控运维。所以我们关于分布式定时任务框架采用了Xxl-job。并且呢我们在许多业务中为了统一技术,在这里针对于我们的定时任务调度,都采用XxlJob作为我们的分布式定时任务调度平台。
21)在后台管理权限这块为什么采用Spring Security,与shiro有什么区别?
我们这个医疗系统中在管理权限技术选型这一块在Spring Security与shiro做了相关的讨论,首先Spring Security是Spring Framework的一部分,可以与其他Spring生态系统中的组件无缝集成它利用了Spring IoC容器和AOP等功能。而Shiro是一个独立的框架,可以与任何Java应用程序集成
其次再授权方式这一块Spring Security和Shiro都支持基于角色和权限的访问控制。但是但在具体的实现上可能有一些区别。比如,Spring Security可以通过注解和表达式来定义访问控制规则,而Shiro则使用基于字符串的权限规则,最后对功能和扩展性也做了相应的比较后,我们这个医疗项目采用了Spring Security来管理权限。
22)在这个项目中你们在哪方面做了优化,问题是怎么解决的?
我们这个医疗项目中比如搜索医生、机构等功能模块在前期数据量比较小的情况下批量导入数据到ES中效率不是特别的慢,也没有太大的服务器压力,但是考虑到后期数据量过大的时候,可能会导致效率会越来越慢,服务器压力也会越来越大,所以对该问题我们做了优化,用xxl-job中的分配策略中的分片广播来优化,首先服务器集群,然后在xxl-job的管理端创建出批量导入数据的定数任务,定时任务启动后用分片广播的形式通知到每一个服务中去,每个服务器根据节点数、数据总数等信息计算出该节点需要处理多少的数据,然后再通过多线程并发执行业务逻辑代码,实现高效率的批量导入数据到ES中去。
23)说说在预约医生这块,你们是怎么保证预约不会出现超约情况?
针对预约这一块我们当时其实也想了许多解决办法,最后通过针对时间、数量、并发等情况对该功能进行了优化去实现的,我就先从时间这一板块来说吧,我们可以对预约的时间进行限制和控制,使预约的时间不会在医生的空闲时间外,然后我们还需要去进行判断当前时间段下,是否存在其他预约的情况,这是我们从时间的角度去思考的,然后就说从数量上去优化,我们可以控制每个时间段只允许相应的预约数量,这个是根据医生的整体情况做出相应调整,以确保医生在这个时间段不会有过多的患者预约,并且你也可以去追踪预约的患者数量,从而进一步阻止预约,然后我们还可以针对并发这一板块去进行优化,就比如这时候多个患者同时进行预约操作可能会导致并发冲突。将所有的预约请求发送到rabbitmq的队列中然后用多线程进行消费队列,这样一来确保在同一时间段内只有一个患者能够成功进行预约操作,以避免超约情况,还可以对预约的状态做实时的更新这里也可以用rabbitmq去进行一个消息的传递,当有患者成功预约后,及时更新预约系统的状态,将该时间段标记为已预约。这样可以避免其他患者在同一时间段内重复预约的问题。
24)你们当前项目中的海量订单是如何解决搜索的?
因为这里存在海量订单的情况下我们查询mysql数据库的话,查询数据量特别庞大可能会查询的影响性能,而且MySQL服务器的内存是有限的,当查询大量数据时,可能会超出服务器的内存限制,导致查询失败或性能下降,为了提升查询时的效率这里我们用了Elasticsearch技术来实现订单的海量查询,简单来介绍下Elasticsearch吧,Elasticsearch采用的是分布式架构主要是可以将数据分散在多个节点上,通过将数据分片存储在不同的节点上,可以实现数据的水平扩展和负载均衡。这使得Elasticsearch能够处理大规模的数据集,而不受单个节点的限制。而且Elasticsearch使用倒排索引的数据结构来加速数据的搜索和检索。倒排索引将每个词条与包含该词条的文档进行关联,从而可以快速定位到包含特定词条的文档。这种数据结构使得Elasticsearch在海量数据中进行快速和高效的搜索操作。Elasticsearch还提供了强大的分布式搜索和聚合功能。通过将查询和聚合操作分发到各个节点处理,并使用分布式计算和数据合并机制,可以加速搜索和聚合操作的执行速度。这使得Elasticsearch能够在海量订单数据中进行复杂的分析和聚合操作。
由于这些原因用Elasticsearch处理海量订单性能可以做到几秒时间查询,真正的解决了项目的烦恼。
25)在后台管理这块数据的统计有没有做过优化,具体是什么优化?
当然是做了优化的,具体方面比较多请容我一一介绍,因为我们是进行后台数据的统计模块嘛,然后需要对大量数据进行统计和计算,这里为了避免一次性加载所有数据到内存中,可以采取批量读取数据的方式进行处理,可以使用poi或者EasyExcel都可以进行批量次数的读取数据操作,减少内存消耗并提高性能,然后对一些被频繁读取的数据我们其实可以使用缓存机制来提高统计计算的效率,将一部分数据或全部的统计结果缓存在内存中,避免了需要进行重复计算,当然我们这里用的是Redis进行存储,也可以利用函数计算来提升性能的优化,因为POI和EasyExcel支持在Excel中使用公式和函数进行计算。可以通过定义合适的公式和函数,将某些统计操作委托给Excel进行计算。这样可以利用Excel自身的优化算法和并行计算能力,提高统计计算的效率。如果是数据量过大的情况下可以考虑使用多线程或并行计算的方式提高效率。将数据分成多个批次,每个批次由独立的线程进行统计计算,然后将结果合并。这样可以充分利用多核处理器和并行计算的优势。
26)用户纠纷,账单金额如何处理?
首先我们会去核对该用户所做的检查项目的所有账单细节,从而来确定对应的相关费用,并与医疗记录进行比对,如果是账单问题,用户点击退款,那么我们可以获取相关账单信息,并验证退款的合法性,根据退款金额和账户信息,调用支付接口进行实际的退款操作。可以使用第三方支付SDK,比如支付宝SDK或微信支付SDK,通过集成相应的SDK实现退款操作,在退款成功后,更新数据库中的账单状态和退款记录。此时会给用户发送退款成功通知。在账单金额退款处理过程中,要确保数据的一致性和完整性非常重要。可以使用事务管理机制,将相关操作包装在一个事务中,在发生错误或异常时进行回滚,保证数据的正确处理。
27)预约挂号的流程具体流程是什么?
我们这个系统的一个预约挂号流程:用户登录完之后,进入首页,用户选择自己对应的科室后,那么系统就会显示该科室下的对应医生列表,用户就可以对标科室,医生进行预约
用户预约完之后此时会出现医生的排班表,用户根据医生的排班时间进行选择,那么用户就需要提供必要的信息填写进系统,用户在填写完之后,需要确认预约的详细信息,系统会将用户给的提交的信息进行回显,当用户点击确认之后会弹出一个支付页面,那么用户完成支付后,此时就会预约成功,预约成功后,此时会生成一张预约挂号单,并向用户发送预约成功通知
28)如何管理采购成本和费用核算?
管理采购成本就要考虑到采购的需求,有医疗设备,药品,材料等相关的数量和质量的要求,此时我们需要找到对应的供应商,那么系统可以通过招标、询价选择合适的供应商,此时不仅考虑价格,还有供应商的一个信誉度,产品质量,售后服务等因素决定。那么就会从这些因素来减少成本的必要的输出,达到管理成本的一个计算。医疗系统对采购的成本进行核算,并进行费用控制。费用核算包括物品价格、运输费用、关税、保险费用等。医疗系统可以通过采购管理软件或系统进行费用核算和成本控制,确保支出的合理性和透明度
29)你们的用户评论医生这块的评论是如何进行审核的?
用户在医疗系统中对医生进行评论时,评论内容会被提交到后端服务器,后端服务器会将用户提交的评论加入一个待审核的队列或数据库表中,用于存储待审核的评论数据。使用风控系统和阿里云访问敏感词库进行审核检测是否存在违反规定的不当行为,如恶意攻击、辱骂等。根据审核结果,将评论的审核状态更新到数据库中,标记评论为已审核或未通过审核。然后可以向用户发送通知,告知评论是否通过审核,以及相关提示信息。
30)你们在评论审核这块有没有做过什么优化?
我们会定期更新敏感词库,添加更多常见的敏感词汇和违规内容,以便更全面地进行审核。也会扩充敏感词库,覆盖更多语言、关键词和上下文信息,以提高审核的准确性和覆盖范围。同时我们结合了人工审核和自动审核,这样可以解决那些自动审核难以判断的情况,增加审核的准确性和可靠性。
31)风控系统是怎么实现?
在用户与医生进行在线咨询时,用户发送的信息在APP端用kafka进行发送消息,风控系统(微服务)监听就会去消费这个消息进行敏感词库本地审核(文本审核,图片审核)判断是否违规,有违规则会进行消息屏蔽,如果风控系统审核判断不了就会去访问阿里云审核,阿里云就会调用本地技术审核完成,APP端拿到审核完成的信息进行持续咨询。
32)为什么使用自敏感词作为首要审核?
(省钱)
首先,调用阿里云的审核服务需要依赖网络连接和第三方服务,而自敏感词审核则是在本地进行的。使用自敏感词作为首要审核可以减少网络请求的延迟和依赖外部服务的风险。无论是在开发过程中还是在实际运行环境中,保持本地的自主性和独立性都是有利的。
其次,使用自敏感词作为首要审核可以更好地适应特定的业务需求和规则。阿里云的审核服务是基于其自有的算法和模型进行敏感内容的识别和过滤。虽然这些服务通常是经过训练和优化的,但可能无法满足所有场景和应用的需求。通过使用自敏感词机制,可以根据具体业务的敏感词清单和规则进行灵活的调整和定制,以确保最佳的审核效果。
此外,自敏感词审核可以提供更高的灵活性和可定制性。阿里云的审核服务,虽然提供了一些参数的配置,但从整体上来说可能不如自敏感词审核那样灵活。使用Java开发的自敏感词审核功能,可以根据具体需求进行算法和逻辑的优化,提升审核的准确性和效率,并且具备更好的可扩展性和可维护性。
最后,使用自敏感词作为首要审核可以降低系统的风险和成本。依赖外部服务意味着可能会面临网络不稳定、服务不可用或者服务费用等问题。而自敏感词审核可以在不依赖外部服务的情况下独立运行,降低了对第三方服务的依赖和相关的风险。同时,自敏感词审核也不需要额外的费用,对于一些资源有限的项目或组织来说,是更经济实惠的选择。
综上所述,使用自敏感词作为首要审核而不是先调用阿里云的审核服务在Java开发中是有一定的优势的。自敏感词审核可以减少依赖外部服务的风险和延迟,更好地适应特定的业务需求和规则,并提供更高的灵活性和可定制性。此外,自敏感词审核还可以降低系统的风险和成本。当然,在实际应用中,也可以结合调用阿里云的审核服务作为补充,以提高审核效果和系统的鲁棒性。
33)在Kafka消息发送这块如何解决不同服务监听相同结果?
这个问题涉及到消息队列的并发处理和消息去重的两个方面。为了解决不同服务器监听到相同结果的问题,可以考虑以下几点。
首先,通过给每条消息设置唯一的标识或者序列号,可以在接收端进行消息的去重处理。发送端在发送消息时,可以为每条消息添加一个全局唯一的标识或者序列号,并将该标识一同发送给消费者。消费者在接收到消息后,通过检查消息的唯一标识来判断是否重复,避免对相同结果的重复处理。
其次,可以利用Kafka的分区功能,将相同结果的消息发送到同一个分区中。这样,在消费者端,只需要让每个服务器监听不同的分区,从而将相同结果的消息分配到不同的服务器上进行处理。通过合理地规划和使用分区策略,可以确保相同结果的消息只被一个服务器处理,避免重复处理的情况发生。
另外,可以在消费者端使用缓存机制,记录已经处理过的消息的标识或者结果,以防止重复处理。消费者可以将已经处理过的消息的标识或者结果存储在内存、本地数据库或者分布式缓存中,每次接收到新的消息时,先检查缓存中是否存在相同标识或结果的消息,如果存在,则直接跳过处理。
最后,还可以考虑使用幂等操作来解决消息重复处理的问题。幂等操作是指对同一操作的多次执行所产生的影响与执行一次的影响相同。通过设计和实现幂等操作,可以确保在重复处理相同结果的消息时,不会产生额外的影响和副作用。
34)你们在风控这块为什么采用kafka作为消息中间件?
Kafka在处理大规模数据流时具有更高的吞吐量和更低的延迟。在风控系统中,需要处理大量的实时事件和交易数据,而Kafka通过其高效的消息存储和分发机制,能够实现每秒处理数十万条甚至更多的消息。相比之下,RabbitMQ虽然也是一个可靠的消息中间件,但在处理大量数据时可能会存在一些性能瓶颈。
其次,Kafka具备可持久化消息存储和容错机制。在风控系统中,确保消息数据的可靠性和完整性至关重要。Kafka使用分布式的日志存储机制,将消息持久化到磁盘,并通过数据复制来提供故障恢复和高可用性。这使得即使在消息发送或接收过程中出现故障,数据也能够得到保留,并且可以被消费者正常处理。相比之下,RabbitMQ将消息存储在内存中,这在某些情况下可能会导致消息的丢失。
此外,Kafka的分布式架构和可扩展性使其能够满足风控系统的高可用性和扩展需求。由于风控系统需要处理大量的并发请求和数据流,所以需要一个能够进行水平扩展的消息中间件。Kafka可以通过分布式和分区机制,将大量的消息均匀分布到多个节点上,从而实现负载均衡和容量扩展。RabbitMQ在这方面的扩展能力相对较弱。
最后,Kafka拥有更广泛的应用场景和更活跃的社区支持。Kafka被广泛用于大规模分布式系统和实时数据处理领域,在风控系统中也得到了广泛应用和验证。Kafka的社区非常活跃,提供了丰富的文档、工具和插件,能够满足风控系统在数据处理、监控和管理等方面的需求。