小花花 的个人动态
  • 小花花 回答了问题
    4小时前

    事件和事件监听器的具体应用场景是什么样的?

    将业务逻辑系统用事件驱动方式拆分,既能使代码逻辑更清晰,又能自主掌控逻辑的同步和异步执行。在业务中很多场景都可以比喻为事件,比如用户注册,可能要求注册之后发送验证信息,或者创建订单之后需要发送订单详情邮件之类的,还有就是批量处理时,可以拆成一个批量输入命令,然后触发一个事件,事件处理一个任务,这个事件触发也可以在接口或者其它地方触发,但是事件监听是同一套,不用做任何修改,如果一块逻辑已经过时,那直接去掉监听即可,代码上可能只需要修改一行即可。

  • 小花花 回答了问题
    5小时前

    如何正确使用redis队列处理php秒杀并发问题?

    高并发时可以使用锁控制抢购或者抽奖,获取到锁了就可以进行购买等行为,获取不到锁就立刻返回,像你说的抢购的人都加入抢购队列,那抢购就有顺序性了,其本身并无顺序性,不能等先来的先抢购,抢购的人有上千万,要造一个上千万的队列吗,再说队列处理到最新加入队列的,那客户不知要等多久了

  • 小花花 回答了问题
    5小时前

    如何正确使用redis队列处理php秒杀并发问题?

    以下方案建议不要用了,rabbitMQ安装方便又好用,比redis做队列直接多了,还不用考虑大部分的问题。

    "用一个线程循环处理",我就不明白该如何下手了,啥时候开启这个"线程"?

    • 我的方案是,先写好一个专门处理队列中的数据的程序,用定时任务(linux的crontab)每分钟调用一次此程序。

    此程序使用blPop或者brPop堵塞获取list的数据(这两个方法的区别可看redis文档得知),要堵塞的原因是,万一这一分钟没有数据,过了30秒后数据进来了,就要再等30秒才能处理。堵塞的最大时间我设了59秒。同时为了兼容大量数据的情况,此程序会循环从list读数据,每次读数据用的都是堵塞方式,所以每次堵塞的时间都会根据当前程序运行的时长动态改变。理论上如果业务不复杂,这个程序运行一次不会超过60秒,也就达到要求了,如果超过了60秒,也会自动新增线程来执行下一次循环。

    你接下来的问题有点不理解,你是了解大的流程的,我说一下这个流程里的细节吧

    我是用redis的list的,其它答案里有提到用锁,如果是你这个方案,完全不需要用锁,因为list已经为你解决了并发问题。

    只要用户点了“抢”,你就把用户的信息lPush或者rPush进一个list,这时会返回一个int,就是告诉你这个操作之后,list里有多少条数据了,这个int是线程安全的,即使再高的并发,也不会造成这个int对于这个用户来说已经过时,所以你可以判断这个int有没有超过库存,如果超过了,直接告诉前端这个用户错过秒杀了,如果否,则让前端等待抢购结果。(此时并不需要把超过库存的用户从list里删除。库存数建议在秒杀前查询出来放到redis中,之后也不要修改redis的库存数,因为这个库存数是专门用于跟list长度做对比的)

    接下来的步骤就根据不同的业务需求了,如果接下来要用户填写补充信息,则最简单了:写一个接口接收用户补充的信息,查询list中用户排第几,跟库存对比一下他是不是真的秒杀到了,然后做入库操作。

    如果接下来没有让用户操作的需要了,则跟上面回答你第一个疑问那样,写一个堵塞轮询的接口。

  • 小花花 提出了问题
    7小时前
  • 小花花 回答了问题
    11小时前

    请问php未来市场占有份额和趋势及应用场景?

    首先瓶颈是什么?

    一般有两种瓶颈:

    1、遇到的业务难题你无法解决,原因是知识储备太少,比如要你去主导做一个订单的服务,每日有海量订单,该怎么做?这种问题就需要自己平时多积累,多关注架构相关的文章,很直接的途径就是,关注各种技术公众号,每天推送,你坚持看就行。

    2、技术难点无法解决,线上问题,如遇到了php coredump问题只能看着,因为你对php内核不熟悉,无法定位,再比如,nginx莫名其妙低频的报各种错误,也摸不着头脑;此时就建议你去学习用到工具的原理与源码,nginx、php、redis、mysql 都坚持要去学。但建议优先学习redis的源码,代码优雅简单,可以掌握大部分常用的数据结构,也知道高性能服务到底怎么去做,可以提升信心。

    还有一个点就是贵在坚持,每天早上早到公司,坚持学习1小时,一年之后你就会改变。

  • 小花花
  • 小花花

    5小时前

  • 这家伙太懒,懒得介绍自己~~~
最近访客
  • 董俊俊
    董俊俊 4小时前