精华内容
下载资源
问答
  • 常见的业务场景

    2020-05-08 13:42:22
    常见的业务场景 场景1:数据涨跌异常如何处理? 场景2:如何评估渠道质量,确定投放优先级? 场景3:一个功能/内容上线后,如何评估其价值? 场景4:如何了解数字背后的用户? 场景5:对于羊毛党,如何查出谁在...

    常见的业务场景

    场景1:数据涨跌异常如何处理?

    场景2:如何评估渠道质量,确定投放优先级?

    场景3:一个功能/内容上线后,如何评估其价值?

    场景4:如何了解数字背后的用户?

    场景5:对于羊毛党,如何查出谁在薅?

     

    场景1:solution

      对比分析,多维度拆解

      常见假设:

        活动影响:查对应活动页面对应动作的数据波动,关注活动是否有地域属性

        版本发布:将版本号作为维度,区分查看

        渠道投放:查看渠道来源变化

        策略调整:策略上线时间节点,区分前后关键指标波动

        服务故障:明确故障时间,按时间维度进行小时/分钟级别拆解

        另外维度拆解可以叠加

    场景2:solution

      常见的渠道划分方式:

      

       渠道质量跟踪:

        ①选择关键事件

          选择反映产品目标人群会做的行为的数据

          例如:

           (电商)购买,(社区)发帖(可衡量各渠道的用户是否为目标用户)

          Χ 完成为期3个月的课程(门槛太高/流程太深,转化率极低,无区分度)

          Χ 打开APP,访问首页(门槛太低,同样缺乏区分度)

        ②查看产生关键事件的用户来源是哪

    场景3:solution

    • 上线后的目标与价值清晰明确

         借助漏斗分析对比(转化关系明确时)

         借助用户分群对比(转化关系较复杂时) 

    • 上线后关注其对产品价值的提升

         借助精准留存对比 

    • 上线后探索更长期的产品潜力

         借助分布情况分析,对比其是否优化了使用频次/场景的分布

          ①产品核心功能使用频次的分布

          ②使用场景(如时间段)的使用

    场景4:solution

      

    高质量拉新:

       

     

     

      ①“真正的用户”: 高留存,核心行为频次、完成率高

      ②“真正的用户”的特征:

    • 是谁(如图书网站,通过用户买卖的书籍推断用户的年龄、受教育程度、地域、消费能力)
    • 从哪儿来(通过电话访谈等方式,发现很多来自朋友推荐的用户)

      ③按此特征,找到类似的用户:

    • 用户画像(倾向社科类书籍;高校,科研所,知识密集型区域)
    • 渠道来源(用人拉人而非广撒网地投放)

    精准运营推送:

        ①运营资源盘活

          [千人一面]整个公司的内部营销资源存在上限

          [千人十面]往往就能解决80%的问题,对应7~8个标签足矣

          [千人千面]人力运营往往难以企及,自动化后或许可以

        ②推送内容与用户有关

         向我说话 x 由我触发 x 和我有关

         

    辅助产品设计:

    • 谁:用户画像
    • 在什么情况下:行为序列的属性
    • 干什么&遇到什么问题:行为序列or屏幕录像

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

          

    展开全文
  • JavaWeb秒杀业务场景设计

    千次阅读 2018-06-10 20:18:23
    秒杀业务场景设计

    秒杀业务场景设计问题经常被面试的时候被问到,在实际业务中,也常常需要实现,下面我们来看看如何实现秒杀业务.

    秒杀业务,是典型的短时大量突发访问类问题

    特点:    秒杀时网站的访问量大增;

                秒杀时购买的请求数量远小于库存,只有部分用户能够成功;

                业务流程简单,根据先后顺序,下订单减库存;

    首先看一下普通商品购买业务的基本逻辑


    那么,秒杀业务,会影响到上面的哪些方面呢


    前端: 

    在同一时段,大量的用户集中访问前端页面的资源,流量剧增,导致页面刷新不及时,甚至无法访问,秒杀系统特点是并发量极大,但实际秒杀成功的请求数量却很少,所以如果不在前端拦截很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时;

    解决方案:(1).当流量过大的时候,加一个验证码可以在单位时间内有效的控制住合法用户;

                    (2).将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素,通过CDN来抗峰值;

                    (3).用户提交之后按钮置灰,禁止重复提交,在某一时间段内只允许用户提交一次请求,比如可以采取IP限流;

    后端:

    传统秒杀系统之所以挂,请求都压倒了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,流量虽大,下单成功的有效流量甚小【一趟火车其实只有2000张票,200w个人来买,基本没有人能买成功,请求有效率为0】

    解决方案:

    站点层设计

    前端层的请求拦截,只能拦住小白用户(不过这是99%的用户哟),高端的程序员根本不吃这一套,写个for循环,直接调用你后端的http请求,怎么整?

    (1)同一个uid,限制访问频度,做页面缓存,x秒内到达站点层的请求,均返回同一页面

    (2)同一个item的查询,例如手机车次,做页面缓存,x秒内到达站点层的请求,均返回同一页面

    如此限流,又有99%的流量会被拦截在站点层。

    服务层设计

    站点层的请求拦截,只能拦住普通程序员,高级黑客,假设他控制了10w台肉鸡(并且假设买票不需要实名认证),这下uid的限制不行了吧?怎么整?

    (请求队列,cache缓存)

    (1)大哥,我是服务层,我清楚的知道小米只有1万部手机,我清楚的知道一列火车只有2000张车票,我透10w个请求去数据库有什么意义呢?对于写请求,做请求队列,每次只透过有限的写请求去数据层,如果均成功再放下一批,如果库存不够则队列里的写请求全部返回“已售完”;

    (2)对于读请求,还用说么?cache来抗,不管是memcached还是redis,单机抗个每秒10w应该都是没什么问题的;

    如此限流,只有非常少的写请求,和非常少的读缓存mis的请求会透到数据层去,又有99.9%的请求被拦住了。

    上面只拦截了一部分访问请求,当秒杀的用户量很大时,即使每个用户只有一个请求,到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机,服务层并发请求压力至少为100W。

    (1). 采用消息队列缓存请求:既然服务层知道库存只有100台手机,那完全没有必要把100W个请求都传递到数据库啊,那么可以先把这些请求都写到消息队列缓存一下,数据库层订阅消息减库存,减库存成功的请求返回秒杀成功,失败的返回秒杀结束。

    (2). 利用缓存应对读请求:对类似于12306等购票业务,是典型的读多写少业务,大部分请求是查询请求,所以可以利用缓存分担数据库压力。

    (3). 利用缓存应对写请求:缓存也是可以应对写请求的,比如我们就可以把数据库中的库存数据转移到Redis缓存中,所有减库存操作都在Redis中进行,然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

    数据库层 

    数据库层是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承担“能力范围内”的访问请求。所以,上面通过在服务层引入队列和缓存,让最底层的数据库高枕无忧。

    接下来详细讲Redis缓存详细思路;

    Redis是一个分布式缓存系统,支持多种数据结构,可利用Redis轻松实现一个强大的秒杀系统。

    实现原理:list双向链表

    此处用到了Redis中的链表(list)数据类型:



           我们可以采用Redis 最简单的key-value数据结构,用一个原子类型的变量值(AtomicInteger)作为key,把用户id作为value,库存数量便是原子变量的最大值。对于每个用户的秒杀,我们使用 RPUSH key value插入秒杀请求, 当插入的秒杀请求数达到上限时,停止所有后续插入。因为pop操作是原子的,即使有很多用户同时到达,也是依次执行.(mysql事务在高并发下性能下降很厉害,文件锁的方式也是).

           然后我们可以再启动多个工作线程,使用 LPOP key 读取秒杀成功者的用户id,然后再操作数据库做最终的下订单减库存操作。

           当然,上面Redis也可以替换成消息中间件如ActiveMQ、RabbitMQ等,也可以将缓存和消息中间件 组合起来,缓存系统负责接收记录用户请求,消息中间件负责将缓存中的请求同步到数据库。

    (1)使用Redis中间件缓存动态资源的好处?

           提高访问速度,减少对数据库的链接的打开、关闭,

    (2)为什么不用JVM内存而使用Redis作为缓存呢?

          JVM 内存较小,隔一段时间会自动进行垃圾回收。
          JVM和业务程序绑定在一起了,如果程序出错,JVM也会停止,这样就导致缓存数据丢失。

          如果使用Redis,除了缓存比较大之外,还实现了缓存数据和业务程序的分离,即使运行程序出现错误,也不会影响缓存。

    压力测试工具

    使用JMeter 压测工具 

    下载、安装、进入C:/JMeter/bin下面的jmeter.bat批处理文件来启动JMeter的可视化界面, 

    进入测试计划添加线程组: 设置线程数,循环次数,添加HTTP默认请求,服务器名称,IP,以及自己设定的携带参数

    添加监听器,存放测试结果:聚合报告,可以表格查询、图形结果、树结果 

    点击运行-》启动。 

    并发量:50W-100W 100W-500W

    以下的文章给了我很多思路

    https://blog.csdn.net/csdn_terence/article/details/77744042

    https://blog.csdn.net/csdn_terence/article/details/77160734

    https://www.cnblogs.com/wangzhongqiu/p/6557596.html

    https://segmentfault.com/a/1190000002990385

    展开全文
  • 简单点说,在以业务目标为边界的业务模型中,业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事,这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事便...

         简单点说,在以业务目标为边界的业务模型中,业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事,这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事便是业务用例了。所以我认为,绘制业务用例图和业务场景图并没有谁先谁后的问题,这两个图是互相验证的。可以先绘制业务场景图,然后把其中的泳道和活动拿出来,得到的就是活生生的业务用例。但根据业务场景图得到的业务用例不一定是完整的,因为可能存在独立的、未参与交互、但仍贡献于整个业务目标的业务用例存在。所以,需要业务用例图与业务场景图进行互相验证。这样才能得到完整并且正确的业务用例。


        到了绘制业务用例场景图的时候,边界必须要缩小了,缩小到每一个业务用例的大小,透过这个边界观看业务用例的内部,看到的是完成这个业务用例所需的步骤,也就是一个人是如何去做一件事的。把边界重新拉大看,这个人做的这件事是完成某个业务目标的一个步骤。正是这些不同的人做的不同的事才构成了整个宏大的业务目标。举个例子,一个人要周游世界(业务目标),那么他需要周游亚洲(业务用例)、周游欧洲(业务用例)、周游拉丁美洲(业务用例)……


        他需要把这些地方都周游过了才能完成周游世界这个伟大的业务目标,于是他可以列出各洲的周游计划表(业务场景图),比如先亚洲、再欧洲、再拉丁美洲……


        周游计划表搞定了,那么仅仅凭这一张空泛的蓝图还是不行的,还需针对每一个步骤设计更详细的各国周游计划表(业务用例场景图)。比如对周游亚洲来说,他要先游中国、再游日本、越南、印度……


        可以看到,一开始的边界是全世界,以这个边界绘制了各洲周游计划表(业务场景图)后,然后再将边界缩小到周游每一个洲上(业务用例),他开始绘制各国周游计划表(业务用例场景图),如果他还觉得不够详尽,还可以以一个国家为边界,绘制游览各风景区的计划表,得到粒度更小的用例。这样边界和抽象层次可以根据需要不断缩小降低,直至得到满意的结果。


        故,从业务建模到系统建模这一整个过程就是一个边界不断缩小、抽象层次不断降低、用例粒度不断变小的过程。以业务目标为边界时,得到的是业务场景图,其中的每一个活动往往都是业务用例;缩小边界到业务用例,得到业务用例场景图,而粒度更小的系统用例就是从该图的活动里筛选出来的;然后可以再缩小边界到每一个系统用例,可以绘制出系统用例场景图,这个时候对用例的建模工作就已经差不多了。而在这个过程当中,不同大小的边界、不同高低的抽象层次是不可交叉的,因为交叉会导致混乱、会将原来自顶向下井井有条的分析过程彻底打乱。可以想象,对于上面的例子来说,当设计各国的周游计划时,不可能出现这种情况:日本--->泰国--->长城--->印度--->欧洲


        再举个例子,当描述一个人的外表时,应当以人的身体外部为边界,从而得到如此词汇:身材高挑、发型整齐、鼻梁挺拔……如果混淆了边界,在这些词汇后突然冒出来一句血压偏低,只会令人莫名奇妙。同样,体检单上也不会出现如下描述:血压正常、心率正常、发型凌乱……


        所以在建模过程中最重要的就是把握边界。但建模过程中的边界有时并不像现实中那样显而易见,一不小心就会逾越边界,我就经常犯错,在以业务目标为视角的用例图中拉进了一大堆不同抽象层次的用例,不同边界的用例交杂在一起,混乱无比,时常把自己搞得也是头昏脑胀。所以这个时候就要多思考、多与同伴讨论、多向高手请教。


    http://se.csai.cn/ANALYZE/201009072221311670.htm

     

    展开全文
  • 如何对业务场景做数据分析?

    千次阅读 多人点赞 2017-05-31 09:37:07
    首先,企业的分析主要分为管理分析和经营业务分析,分析整体的思路是:明确业务场景——确定分析目标——构建分析体系——梳理核心指标。因为每个企业/行业的业务不同,分析体系也不同,这里主要说一下零售电商,...

    企业的数据分析是个很复杂的工程,需要业务和分析技术两块知识。这里从业务的角度切入,谈谈如何对业务分析,文章参考帆软软件的零售业数据管理方案。

    首先,企业的分析主要分为管理分析和经营业务分析,分析整体的思路是:明确业务场景——确定分析目标——构建分析体系——梳理核心指标

    因为每个企业/行业的业务不同,分析体系也不同,这里主要说一下零售电商,按照不同的分析场景来探讨下。其他行业也欢迎大家勾搭,或者可以看看这个专栏里里的案例(比较偏向报表体系,有一定借鉴意义):帆软数据应用研究院

    以电商为例,常用的业务分析场景有销售、商品、渠道、竞品、会员等等,而商品可进一步细分为商品的库存、商品的利润以及关联销售分析。在整个业务分析体系中,电商行业遵循“人货场”的思维逻辑,其指标可这样划分:


    1、销售类分析

    销售分析主要是为了追踪销售情况,与KPI对比,调整销售策略,进一步提升销售额。

    分析思路:基本上任何一个问题都可以套用“人货场的模型来分析”。比如分析客单价下降的原因,从人货场角度切入的话,可建立如下的分析模型:


    分析方法:数据分析可通过数据对比、极值、预测的方式来分析

    • 对比:比如事业部销售额排行榜、销售额贡献度、城市排行榜等等

    • 极值:比如月销售额最高纪录,激励销售人员或事业部突破记录

    • 预测:根据权重曲线预测未来的销售额

    2、商品分析

    商品分析是基于商品的一个流程管理——进销存。比如商品库存太大,占用资金,则采购进货不合理;商品陈列不合理,造成发货不及时,销售滞后。

    商品分析体系——“进销存”思路,常用的指标如商品的折扣率、动销率、周转率等。


    3、会员数据分析

    会员数据分析一方面是可以指导销售营运,另一方面是提高营销的精准度,增加用户的粘性,减少流失。

    会员分析管理体系:

    如何对业务场景做数据分析?

    4、其他管理分析

    人力资源管理中的数据分析一般包括两个方面,一方面是人员结构分析,另一方面是人力效能的分析。在人效分析过程中最关注两个指标,人均产出和人员费用产出率。人员结构分析包括不同职能部门的人力结构、不同层级的人才结构、不同工作年限的人才结构等等。分析人力结构是防止人才的断层,在招聘上做好预案,优化薪酬分布。

    数据分析领域的财务主要是管理财务,管理财务需要细化到每个子公司、每个业务、每个产品、每个业务部门、每个客户,以他们为主题的分析有:现金流分析、盈利能力分析、财务预算分析等。

    这里只是概述了一个框架,每一个点展开都是一门知识,欢迎留言探讨~

    展开全文
  • **Redis**的常用业务场景 1、热点数据的缓存 由于redis访问速度比较快、支持的数据类型比较丰富,所以redis很适合存储热点数据,另外结合expire,我们可以设置过期时间在进行缓存更新操作,这个功能最为常见,...
  • 一文搞懂分布式锁及其业务场景

    千次阅读 多人点赞 2019-09-12 09:40:04
    在讨论这个问题之前,我们先来看一个业务场景: 系统A是一个电商系统,目前是一台机器部署,系统中有一个用户下订单的接口,但是用户下订单之前一定要去检查一下库存,确保库存足够了才会给用户下单。 由于系统有...
  • 假如没有靠谱的公司,接触不到高并发的业务场景怎么办? 从处理技巧上,可以通过大牛学习高并发的架构,比如张宴:张宴的博客 - Web系统架构与底层研发.至少你可以知道处理高并发的业务逻辑是: 前端:异步请求+资源静态....
  • TiDB 作为一款高效稳定的开源分布式数据库,在国内外的银行、证券、保险、在线支付和金融科技行业得到了普遍应用,并在约 20 多种不同的金融业务场景中支撑着用户的关键计算。在TiDB 在金融行业关键业务场景的实践...
  • ...从底层的机器监控到直面用户的应用,都离不开时序性的业务场景,而时序性的数据一般都由专业的时序数据库来存储分析,下面主要介绍 TSDB 覆盖的业务场景以及面临的挑战。 1.1 时序数据库覆...
  • 业务场景和业务用例场景的区别(作者:Arthur网友)

    万次阅读 热门讨论 2009-06-01 16:08:00
    简单点说,在以业务目标为边界的业务模型中,业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事,这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事...
  • 在多租户用户管理系统中,常见的业务场景有以下几种:用户注册用户通过填写手机号码等信息,进行注册操作;该场景这重验证用户手机号码的有效性,一般通过短信验证码进行验证;租户注册用户通过填写租户的相关信息,...
  • 业务场景测试

    千次阅读 2018-12-27 10:18:38
    将系统的不同模块进行有效串接,继而模拟真实用户的实际使用情况对系统进行运营,促使系统能够充分满足用户所要求的功能的测试过程其实就是业务测试。 简而言之,就是多个功能组合测试。 2 为什么要做业务测试 从...
  • 乐观锁的业务场景及实现方式

    千次阅读 2020-02-10 17:22:35
    乐观锁的业务场景及实现方式 每次获取数据的时候,都不担心数据被修改,所以每次获取的数据的实话都不会进行加锁,但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改,则不进行数据更新...
  • 订单业务场景测试设计 1、订单完成流程图 2、手动确认订单业务场景用例设计 ID 模块 优先级 前置条件 测试标题 步骤描述 测试数据 预期结果 实际结果 测试版本号 测试人员 ...
  • 策略模式在实际业务场景中的使用及优化 策略模式(Strategy Pattern):定义不同的策略算法,以达到新增算法、移除算法、修改算法的便利性和调用无感知,并且不同的算法区分开之后也更加方便阅读策略算法。(个人...
  • 多租户用户管理常用业务场景

    万次阅读 2016-11-23 21:50:34
    在多租户用户管理系统中,常见的业务场景有以下几种: 用户注册 用户通过填写手机号码等信息,进行注册操作;该场景这重验证用户手机号码的有效性,一般通过短信验证码进行验证; 租户注册 ...
  • 本次以共享快递柜业务场景讲解topic和payload的设计。 在共享快递柜场景中,我们会涉及到C端用户操作: 在App端扫码,操作快递存取,触发后台下发指令到当前机柜,执行相关操作。 用户存取完毕,触发订单结算或其他...
  • SAP解决方案(典型业务场景

    千次阅读 2018-06-28 11:08:12
    一、SAP解决方案 在华为云上部署SAP业务,能够充分利用华为云大规格、高性能、高安全和高可靠的能力,以及全生命周期的管理服务,帮助企业简化管理、节省成本、高效运营,快速实现数字化转型 1、典型业务场景: ...
  • 哪些业务场景不适合部署在虚拟机上? 原创: 点击蓝字关注
  • Hadoop一般用在哪些业务场景

    千次阅读 2016-12-05 16:12:29
    带着这个问题渗透到业务中去分析,就知道hadoop需要应用到什么业务场景了!!!如果关系型数据库都能应付的工作还需要hadoop吗? 比如 1.银行的信用卡业务,当你正在刷卡完一笔消费的那一瞬间,假如在你当天消费...
  • HTTPS与httpdns一起用的业务场景解决方案
  • SAP业务上云是企业服务化转型的重要趋势,企业在上云的投入持续增长,在零售、能源、汽车、制药等行业表现的尤为明显,SAP业务部署在传统IT基础...为了解决大家的疑惑,华为云SAP解决方案团队特意推出四大业务场景...
  • 业务场景驱动的服务型CMDB

    千次阅读 2016-11-16 14:25:14
    但各种业务场景表明,当下数据中心运维,CMDB依然是不可或缺的一部分,它承载着运维的基础,掌握运维的命脉。 分析以往失败的案例,静静的想一想,失败无非两点: 一、CMDB自身建设能力不够,无法适应当下数据...
  • 以及熟练SpringCloud各个技术栈之后将会进行模拟业务场景高可用微服务搭建,整合高可用搜索引擎、缓存架构,数据分库分表以及海量模拟数据测试,高并发测试。 指南 一、快速学习SpringCloud所涉及的技术栈 1、服务...
  • 后台订单处理业务场景测试设计 流程步骤: 设计测试用例: 第一步:绘制流程图 1、确认业务中的操作 2、分析执行的顺序 3、按照业务方向进行连线 收到前台订单(商城->订单->订单列表) 订单确认 ...
  • Silverlight的业务场景

    千次阅读 2007-07-24 08:48:00
    下文是我目前正在写的Silverlight White paper其中一章,主要用来介绍Silverlight的业务场景,还没有最终定稿,现在发布在此处,希望征集一些大家的意见反馈,同时,也欢迎更多的朋友来交流Silverlight的业务场景。...
  • 事实上,只要在业务场景中涉及了支付,出现了交易、资金的转移的过程,就一定会产生清算、结算的需求。那么在实际的业务场景中究竟存在着怎样的支付清结算需求?为了寻找问题的答案,我们不妨从小贷的例子入手来一探...
  • 文章目录一、CO记账数据来源的业务场景二、业务场景示例2.1 业务场景一示例2.2 业务场景二示例三、记账数据对应数据库表3.1 数据库表清单3.2 COSP、COSS相关字段详解3.3 在表中查询前台业务数据3.3.1、COSP3.3.2、...
  • 业务场景篇 Spring的概述  Spring是完全面向接口的设计,降低程序耦合性,主要是事务控制并创建bean实例对象。在ssh整合时,充当黏合剂的作用。IOC(Inversion of Control) 控制反转/依赖注入,又称DI(Dependency ...
  • 比如某系统有三个子系统,登录系统、积分系统群、日志系统群。 一个用户登录了系统,将发送通知给...实际业务场景特点: 子业务系统都有集群的可能性 同一个消息会广播给关注该类消息的所有子业务系统 同一类消...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 56,547
精华内容 22,618
关键字:

业务场景