精华内容
下载资源
问答
  • 数据库,部分函数依赖,传递函数依赖,完全函数依赖,种范式的区别

    要讲清楚范式,就先讲讲几个名词的含义吧:

    部分函数依赖:X,Y是关系R的两个属性集合,存在X→Y,若X’X的真子集,存在X’→Y,则称Y部分函数依赖于X

    举个例子:学生基本信息表R中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);


    完全函数依赖:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。

    例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级);


    传递函数依赖:设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。

    例子:在关系R(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,所以符合传递函数的要求;

     

     1 、第一范式(1NF)

      在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。

      所谓第一范式(1NF)是指数据库表的每一列(即每个属性)都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之,第一范式就是无重复的列。

      2、 第二范式(2NF)

      第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。

      第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是非主属性依赖于主关键字。

      3 、第三范式(3NF)

      满足第三范式(3NF)必须先满足第二范式(2NF)。在满足第二范式的基础上,切不存在传递函数依赖,那么就是第三范式。简而言之,第三范式就是属性不依赖于其它非主属性。

    最后简单的总结一下:

    1第一范式(1NF):一个关系模式R的所有属性都是不可分的基本数据项。 

    2第二范式(2NF):关系模式R属于第一范式,且每个非主属性都完全函数依赖于键码。 

    3第三范式(3NF):关系模式R属于第一范式,且每个非主属性都不伟递领带于键码。 

    4 BC范式(BCNF):关系模式R属于第一范式且每个属性都不传递依赖于键码


    第三范式以上的范式在数据库中也很少用到,而且三级数据库一般也不会考,这里就不提了吧,呵呵,偷个懒

     

    展开全文
  • B/S层架构[转载]

    万次阅读 2010-11-30 13:05:00
    层架构(3-tier application) 通常意义上的层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。 1、表现层(UI):通俗讲...

     

    三层架构 (3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。
      1、表现层( UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
      2、业务逻辑层( BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
      3、数据访问层( DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。
    在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层。
      三层结构原理:
       3个层次中,系统主要功能和业务逻辑都在业务逻辑层进行处理。
      所谓三层体系结构,是在客户端与数据库之间加入了一个 “中间层”,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。
      三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过 COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。
       表示层
     位于最外层(最上层),离用户最近。用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。
      
       业务逻辑层
     业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中,将整个架构分为三个主要的层:表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans,对业务逻辑层作了更细致地划分,细分为应用层与领域层,通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
      
      业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是 “无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。
       数据层
     数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问,可以访问数据库系统、二进制文件、文本文档或是XML文档。
      
      简单的说法就是实现对数据表的 Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。
    与MVC的区别
       MVC(模型Model-视图View-控制器Controller)是一种设计模式,我们可以用它来创建在域对象和UI表示层对象之间的区分。
      同样是架构级别的,相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。

      在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是已实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。

    展开全文
  • 什么是消息推送?

    万次阅读 2018-05-09 10:45:08
    今天给大家分享一下,修真院官网pm task9的知识点——什么是消息推送?.背景介绍1.推送基础移动互联网蓬勃发展的今天,大部分手机 APP 都提供了消息推送功能,如新闻客户端的热点新闻推荐,IM 工具的聊天消息提醒...

    大家好,我是IT修真院上海分院3期的学员,一枚正直纯洁善良的PM。

    今天给大家分享一下,修真院官网pm task9的知识点——什么是消息推送?

    一.背景介绍

    1.推送基础

    移动互联网蓬勃发展的今天,大部分手机 APP 都提供了消息推送功能,如新闻客户端的热点新闻推荐,IM 工具的聊天消息提醒,电商产品促销信息,企业应用的通知和审批流程等等。推送对于提高产品活跃度、提高功能模块使用率、提升用户粘性、提升用户留存率起到了重要作用,作为 APP 运营中一个关键的渠道,对消息推送的合理运用能有效促进目标的实现。

    推送最早诞生于 Email 中,用于提醒新的消息,而移动互联网时代则更多的运用在了移动客户端程序。

    2.消息推送概念

    消息推送(Push)指运营人员通过自己的产品或第三方工具对用户移动设备进行的主动消息推送。用户可以在移动设备锁定屏幕和通知栏看到push消息通知,通知栏点击可唤起APP并去往相应页面。我们平时在锁屏上看到的微信消息等等都属于APP消息推送行列。 推送(Push)是一种技术概念,是指从服务端实时发送信息到客户端。 大家概念中的典型推送服务是类似 APNS(Apple Push Notification Service)、GCM(Google Cloud Messaging) 等服务。在国内,由于谷歌服务不能使用,因此您的应用必须使用第三方或者自己研发的服务来推送。

    3.推送的利弊

    优点:

    (1).提高活跃度和用户粘性

    APP消息推送可以直接唤醒APP,是获得用户特别关注,并打开APP激活使用的绝佳途径。运营人员身上背着日活,月活的KPI,APP消息推送也是大部分运营人员完成KPI的途径之一。

    (2).提高用户留存率

    APP运营的竞争,在于抢夺用户关注时间,所以大部分不具高频次特性的工具类产品,用户用过则过。所以为了唤醒沉睡用户,挽留流失用户,APP消息推送也身兼一定的作用。

    (3).提高产品功能和营销活动的用户参与度

    APP上有新的营销活动或者APP有新的功能发出,用户不一定感知到,现在APP功能做的越来越复杂,为了完成KPI,营销活动越来越多,用户主动发掘的欲望很低,好的功能一定要想办法让用户感知到,这是提升用户体验的非常好的途径。

    缺点:

    (1).对用户形成打扰,招致卸载。提高活跃度的同时也能招致高卸载率。

    (2).用户对推送消息变得麻木。

    (3).产品丧失用户信任。用户下载使用代表着对APP的信任,透支这份信任必然用户会丧失好感。

    4.相关指标

    (1).到达率

    到达率=(用户接收 / 推送数量)*100%

    (2).点击率

    点击率= (点击人数/ 用户接收数)*100%

    (3).转化率

    转化率=(目标行为人数 / 用户点击数)*100%

    (4).投资回报率

    ROI = (新增收入/投入费用)*100%

    二.消息分类

    1.短信推送

    短信推送凭借着优秀的到达率,一度成为最受欢迎的营销工具之一。短信推送是通过正规短信供应商发送,发送率和抵达率高,短信内容需要提前报备,根据发送量不同价格不一样,越多越便宜。

    短信协议:指的是手机所支持的短信息协议,也称为多媒体协议。目前主要有SMS短信、EMS短信和MMS彩信三种。

    SMS(Short Messaging Service)即:短信服务。是最早的短消息业务,也是现在普及率最高的一种短消息业务,通过它移动电话之间可以互相收发短信,内容以文本、数字或二进制非文本数据为主,这种短消息的长度被限定在140字节之内。SMS以简单方便的使用功能受到广大用户的欢迎,迅速普及,但却始终是属于第一代的无线数据服务,在内容和应用方面存在技术标准的限制。

    SMS短信结构:【签名】+(文案)+(短链)+退订


    缺点:容易被拦截。


    2.邮件推送

    EDM邮件:EDM 是 Email Direct Marketing 的缩写,即电子邮件营销。企业可以通过EDM建立同目标顾客的沟通渠道,向其直接传达相关信息,用来促进销售。可以发送电子广告、产品信息、销售信息、市场调查、市场推广活动信息等。


    EDM的优点

    1.精准直效:

    可以精确筛选发送对象,将特定的推广信息投递到特定的目标社群。

    2.个性化定制:

    根据社群的差异,制定个性化内容,让企业根据用户的的需要提供最有价值的信息。

    3.信息丰富,全面:

    文本,图片,动画,音频,视频,超级链接都可以在EDM中体现。

    4.具备追踪分析能力 :

    根据用户的行为,统计打开邮件, 点击数并加以分析,获取销售线索。


    EDM注意事項

    1.标题

    务必吸引人。但是前提是要表述清楚内容同时不要过长。

    2.页面内容:

    因为使用图片无可避免,但是,重要的内容请务必使用文字,哪怕是使用了图片也务必给出文字标识!

    3.图片的使用:

    建议给每个图片一个固定的宽度和高度及Alt属性标识,同时,注意不要使用背景图片。

    4.一致性:

    如果你会定期发送EDM,请注意使用统一的风格,主要是页头和页尾的风格统一。如果,你是有期刊号的请将期刊号和时间也一并加入!


    3.通知栏推送

    通知栏推送,即指在手机的通知栏上会显示的一条通知信息。用户可以在移动设备锁定屏幕和通知栏看到push消息通知,通知栏点击可唤起APP并去往相应页面。可以有效激活用户,提升用户活跃。


    4.应用内推送

    应用内推送主要是弹窗。弹窗的样式可以设置成多种多样。


    三.移动消息推送平台的构建

    移动推送的三种实现方式

    1.轮询方式(PULL)

    客户端和服务器定期的建立连接,通过消息队列等方式来查询是否有新的消息,需要控制连接和查询的频率,频率不能过慢或过快,过慢会导致部分消息更新不及时,过快会消耗更多的资源(流量、电量等),对用户体验有较大伤害。

    2.短信推送方式(SMS PUSH)

    通过短信发送推送消息,并在客户端植入短信拦截模块(主要针对 Android 平台),可以实现对短信进行拦截并提取其中的内容转发给 App 应用处理,这个方案借助于运营商的短消息,能够保证最好的实时性和到达率,但此方案对于成本要求较高,开发者需要为每一条 SMS 支付费用。

    3.长连接方式(PUSH)

    移动 Push 推送基于 TCP 长连接实现, 客户端主动和服务器建立 TCP 长连接之后, 客户端定期向服务器发送心跳包用于保持连接, 有消息的时候, 服务器直接通过这个已经建立好的 TCP 连接通知客户端。尽管长连接也会造成一定的开销,对于轮询和 SMS 方案的硬伤来说,目前已经是最优的方式,而且通过良好的设计,可以将损耗降至最低。不过,随着客户端数量和消息并发量的上升,对于消息服务器的性能和稳定性要求提出了非常大的考验。因此,就难度而言,此方式代价最高。

    推送解决方案

    基于 TCP 长连接的方式是主流的推送方式,基于该推送方式逐步发展出系统级、应用级一系列的推送解决方案。

    系统级方案

    1.iOS 平台(APNs)

    iOS 在系统层面与苹果 APNs(Apple Push Notification service)服务器建立连接,应用通过观察者模式向 ioS 系统注册关注的消息,系统收到 APNs Server 消息后转发到相应的应用程序,整个过程很清晰,并且所有 APP 都共用同一个系统级的连接,减少了系统开销,虽然 APNs 能无障碍的访问,但实际使用过程中,发现延时和丢消息的情况偶有发生。


    2. Android 平台(C2DM)

    Android 的 C2DM(Android Cloud to Device Messaging)采取与 iOS 类似的机制,都是由系统层面来支持消息推送,但是由于 Google 的服务在国内不能稳定的访问,此方案对于中国用户来说基本是无法使用的。 除了 Google 官方提供的方案,中国众多的手机厂商在其定制的系统中也内置了推送功能,如小米、华为等。


    应用级方案

    1.第三方推送服务

    鉴于 Android 平台 C2DM 推送的不可用性,国内涌现出大量的第三方推送服务提供商.目前应用最为广泛的第三方推送服务提供商包括个推、极光、友盟、小米、华为、BAT 等,绝大部分 APP 都会优先考虑采用第三方推送服务。

    2.自建推送服务

    第三方服务在开发成本和消息到达率上表现都不错,但所有信息会经过第三方服务器,对于信息敏感类 APP 而言,有必要考虑自建一套消息推送服务,能最大化保证安全,但对于自建推送服务,如果从零开始来做需要解决几个难点: 第一,移动推送服务器对 App 客户端海量长连接的维护管理。第二,App 客户端如何保证 Push Service 常驻,对于 Android 我们可以通过发现 push service 不存在可以定时拉起的方式。第三,通信协议的制定,我们可以采用开源的 XMPP 方式实现,也可以自定义协议,不管哪种方式我们都要保证消息传送的到达率的准确性。第四,在移动互联网网络环境下,经常出现弱网环境,特别是 2G、3G 等网络不稳定的情况下,如果保证消息在弱网环境下不重、不丢也是一个挑战。

    四.如何构建消息推送策略

    1、明确消息通知的类型

    产品价值是用户为何活跃于产品的原因,而消息通知则是产品核心价值的延伸。消息通知从形态来分划分,可以归纳成营销型,功能型和内容型三类。使用哪一种取决于要传递的是产品哪一方面的价值以及每种方式的限制。

    营销型

    通常发送给全量的用户,电商类APP例如淘宝、京东使用较为频繁,给用户发送活动大促,限时抢购,优惠红包等信息通知。


    优势:能够覆盖所有用户;研发成本低,可以直接接入第三方推送API

    劣势:内容没有个性化,导致点击率较低;频繁发送易形成打扰,而且部分用户对于该类内容忍耐度低,必须谨慎使用,避免用户卸载或投诉

    功能型

    基于用户自身在APP上的行为触发消息推送,通知用户一些事务型的消息,例如闪惠买单成功,红包领取到账等等。


    优势:内容与用户强联系,个性化,交互度较高;用户理解消息触发的原因,对于消息通知的容忍度较高。

    劣势:覆盖人群较窄,用户需要与产品有足够多的交互或者与足够多的其他用户连接,才能有消息通知的触发,无法触达一些低频乃至新用户。

    内容型

    将用户感兴趣或可能喜欢的内容进行连接,一般基于用户的浏览,收藏,点赞,关注等行为,进行个性化的内容推荐。


    优势:通过高度定制化与用户相关内容获得较高的交互度,仅此于功能型的点击率;没有足够信息进行个性化推荐的情况下,可以通过推送热门内容覆盖较多用户。

    劣势:用户如果与产品交互少,导致产品获取信息少或者内容不够精准,带来的交互度也会较低。从技术实现来看,实现推荐算法的成本较高。

    2.明确用户类型

    明确了推送的意义,该推送什么内容,接下来需要明确推送给谁,不是所有的消息推送对于所有的用户都是有价值的.消息要基于人群的共性进行划分,在进行有针对性的推送。不可取的反例就是给男生推送美甲优惠信息,给尚未结婚的大学生推送亲子促销信息,以上内容的推送极易造成用户的反感。


    从生命周期维度细讲。APP的用户可简单的分为新用户、低频用户、活跃用户。

    新用户,推送能够强化产品价值的消息,帮助用户了解产品的功能特性,明确怎样从产品中获得更多的价值,来提高自身的效率。

    活跃用户,对产品有较深的理解,用户的画像较为精准,可以推送更多个性化的内容,让他们与产品有更多交互。

    低频用户,对产品可能不太认可,用户的画像也不够精确。为了让他们与产品产生更多的交互,应降低推送的频率,推送较为普适的内容或真正力度较大的促销活动较为有效。

    3.提升消息通知精准性

    推送的时间

    从用户使用场景出发,选择合适的推送时间。不要在晚上10点以后发送消息通知,影响用户休息等对用户形成打扰都是不友好的行为。

    比如天气类APP,通常用户会在早上出门前想知道一整天的天气情况、温度变化,因此天气类APP最好的推送时机就是早上8-9点。

    比如外卖类APP,暴雨或酷热等恶劣天气,用户往往不愿意出门就餐,推送一些高温红包补贴等通知会较为有效。

    用户的位置

    iOS和Android对于位置信息都有很好的支持,根据用户的GPS位置信息可以进行推送个性化的内容推送。

    比如异地的场景,当感知到用户到达了陌生的城市,可以给用户推送当地的美食排行、酒店攻略以及旅游门票类信息。

    比如常居地的场景,可以给用户推送周边新开的热门美食店、玩乐场景,帮助用户探索新的消费场所。当用户到达商场综合体,可以推送商场内的最新活动讯息。

    手机的型号

    针对Android和iOS手机不同的特性和面向人群进行针对性的推送。Android各厂商对消息通知的支持能力也不同,从实际的数据反馈,小米和华为的Push消息通道相比,小米的消息通知的触达率会高很多。

    iOS10对于消息推送推送进行了全新的升级,可以发送图片、音频、视频等内容,用户还可以对消息通知进行喜欢、退订等自定义按钮的交互。

    五.参考文献

    参考1:消息推送常见问题索引

    参考2:如何构建一套高可用的移动消息推送平台?

    六.更多讨论




    PPT:

    什么是消息推送?

    视频:




    class="player" src="//v.qq.com/iframe/player.html?vid=v0535iplaag&tiny=0&auto=0" width="620" height="517" allowfullscreen="">
    收起视频
    什么是消息推送?
          </div>
    
    展开全文
  • 消息队列系列之分布式消息队列Kafka

    万次阅读 2017-12-03 20:00:11
    ApacheKafka®是个分布式流媒体平台。这到底是什么意思呢? 我们认为流媒体平台具有个关键功能: 它可以让你发布和订阅记录流。在这方面,它类似于消​​息队列或企业消息传递系统。它允许您以容错方式存储记录...

    介绍

    ApacheKafka®是一个分布式流媒体平台这到底是什么意思呢?

    我们认为流媒体平台具有三个关键功能:

    1. 它可以让你发布和订阅记录流。在这方面,它类似于消​​息队列或企业消息传递系统。
    2. 它允许您以容错方式存储记录流。
    3. 它可以让您在发生记录时处理记录流。

    什么是卡夫卡好?

    它被用于两大类的应用程序:

    1. 构建可在系统或应用程序之间可靠获取数据的实时流数据管道
    2. 构建实时流应用程序,可以转换或响应数据流

    要了解卡夫卡如何做这些事情,让我们深入探索卡夫卡的能力。

    首先几个概念:

    • Kafka作为一个或多个服务器上的集群运行。
    • Kafka集群以称为主题的类别存储记录
    • 每个记录由一个键,一个值和一个时间戳组成。

    卡夫卡有四个核心API:

    • 制片API允许应用程序发布的记录流至一个或多个卡夫卡的话题。
    • 消费者API允许应用程序订阅一个或多个主题,并处理所产生的对他们记录的数据流。
    • 所述流API允许应用程序充当流处理器,从一个或多个主题消耗的输入流,并产生一个输出流至一个或多个输出的主题,有效地变换所述输入流,以输出流。
    • 连接器API允许构建和运行卡夫卡主题连接到现有的应用程序或数据系统中重用生产者或消费者。例如,连接到关系数据库的连接器可能会捕获对表的每个更改。

    在Kafka中,客户端和服务器之间的通信是通过一个简单的,高性能的,与语言无关的TCP协议完成的这个协议是版本化的,并保持与旧版本的向后兼容性。我们为Kafka提供了一个Java客户端,但客户端可以使用多种语言

    主题和日志

    让我们先深入核心抽象Kafka提供了一个记录流 - 主题。

    主题是要将记录发布到的类别或供稿源名称。卡夫卡的话题总是多用户的; 也就是说,一个主题可以有零个,一个或多个订阅写入数据的消费者。

    对于每个主题,Kafka集群维护一个分区日志,如下所示:

    每个分区是一个有序的,不可变的记录序列,不断追加到结构化的提交日志中。分区中的记录每个分配一个连续的id号,称为偏移量,用于唯一标识分区内的每条记录。

    Kafka集群使用可配置的保留期限来保留所有已发布的记录(无论是否已被使用)。例如,如果保留策略设置为两天,则在记录发布后的两天内,保留策略可供使用,之后将被丢弃以腾出空间。卡夫卡的性能在数据大小方面是有效的,所以长时间存储数据不成问题。

    实际上,以消费者为单位保留的唯一元数据是消费者在日志中的偏移或位置。这个偏移量是由消费者控制的:消费者通常会在读取记录时线性地推进其偏移量,但事实上,由于消费者的位置是由消费者控制的,所以它可以以任何喜欢的顺序消费记录。例如,消费者可以重置为较旧的偏移量以重新处理来自过去的数据,或者跳至最近的记录并从“now”开始消费。

    这些功能的组合意味着卡夫卡的消费者非常便宜 - 他们可以来来去去,对集群或其他消费者没有太大的影响。例如,您可以使用我们的命令行工具来“尾巴”任何主题的内容,而不会改变现有的使用者所使用的内容。

    日志中的分区有几个用途。首先,它们允许日志的大小超出适合单个服务器的大小。每个单独的分区必须适合托管它的服务器,但是一个主题可能有许多分区,因此它可以处理任意数量的数据。其次,它们作为并行的单位 - 更多的是在一点上。

    分配

    日志的分区分布在Kafka集群中的服务器上,每个服务器处理数据和请求共享分区。每个分区都通过可配置数量的服务器进行复制,以实现容错。

    每个分区有一个服务器充当“领导者”,零个或多个服务器充当“追随者”。领导处理分区的所有读取和写入请求,而追随者被动地复制领导。如果领导失败,其中一个追随者将自动成为新领导。每个服务器充当其中一些分区的领导者和其他人的追随者,因此负载在集群内平衡良好。

    生产者

    生产者发布数据到他们选择的主题。生产者负责选择哪个记录分配给主题内的哪个分区。这可以以循环的方式完成,只是为了平衡负载,或者可以根据某些语义分区功能(例如基于记录中的某个键)来完成。更多关于使用分区在第二!

    消费者

    消费者用消费者组名称标记自己,并且发布到主题的每个记录被传递到每个订阅消费者组中的一个消费者实例。消费者实例可以在不同的进程中或在不同的机器上。

    如果所有消费者实例具有相同的消费者组,则记录将有效地在消费者实例上进行负载均衡。

    如果所有消费者实例具有不同的消费者组,则每个记录将被广播给所有消费者进程。

    两个服务器Kafka集群托管四个分区(P0-P3)与两个消费者组。消费者组A有两个消费者实例,而组B有四个消费者实例。

    然而,更普遍的是,我们发现话题中有少量消费群体,每个“逻辑用户”都有一个消费群体。每个组由许多消费者实例组成,具有可扩展性和容错性。这不过是发布 - 订阅语义,订阅者是一群消费者而不是一个进程。

    在Kafka中实现消费的方式是将日志中的分区划分为消费者实例,以便每个实例在任何时间点都是“公平分享”分区的唯一消费者。这个维护组中成员资格的过程是由Kafka协议动态地处理的。如果新实例加入组,他们将接管来自组中其他成员的一些分区; 如果一个实例死亡,其分区将分配给其余的实例。

    卡夫卡只提供一个区内记录总数,而不是主题中的不同分区之间。每个分区排序与按键分区数据的能力相结合,足以满足大多数应用程序的需求。但是,如果您需要全部订单而不是记录,则可以通过仅具有一个分区的主题来实现,但这意味着每个消费者组只有一个消费者进程。

    担保

    在一个高层次的卡夫卡提供以下保证:

    • 由制作者发送到特定主题分区的消息将按照它们发送的顺序附加。也就是说,如果记录M1由同一个生产者作为记录M2发送,并且M1被首先发送,则M1将具有比M2更低的偏移并且出现在日志中的更早。
    • 消费者实例按照存储在日志中的顺序查看记录。
    • 对于具有复制因子N的主题,我们将容忍多达N-1个服务器故障,而不会丢失任何提交给日志的记录。

    有关这些保证的更多细节在文档的设计部分给出。

    卡夫卡作为消息系统

    卡夫卡的流概念如何与传统的企业消息传递系统相比较?

    消息传统上有两种模式:排队发布 - 订阅在队列中,消费者池可以从服务器读取并且每个记录都转到其中的一个; 在发布 - 订阅记录被广播给所有消费者。这两种模式都有其优点和缺点。排队的优势在于它允许您将数据处理划分为多个消费者实例,这样可以扩展处理。不幸的是,队列不是多用户的,一旦一个进程读取了数据,发布 - 订阅允许您将数据广播到多个进程,但无法进行扩展处理,因为每条消息都发送给每个订阅者。

    卡夫卡的消费群体概念概括了这两个概念。与队列一样,消费者组允许您将一系列流程(消费者组的成员)的处理分开。与发布 - 订阅一样,Kafka允许您向多个消费者群体广播消息。

    Kafka模型的优点是每个主题都具有这些属性 - 它可以扩展处理,也可以是多用户 - 不需要选择其中一个。

    Kafka也比传统的消息系统有更强的订单保证。

    传统队列在服务器上按顺序保留记录,并且如果多个使用者从队列中消耗,则服务器按照它们存储的顺序来提交记录。但是,虽然服务器按顺序提交记录,但是记录是异步传递给消费者的,所以它们可能会针对不同的消费者而出现故障。这实际上意味着记录的排序在并行消耗的情况下丢失。消息传递系统通常具有“排他消费者”的概念,只允许一个进程从队列中消费,但这当然意味着在处理过程中没有并行性。

    卡夫卡做得更好。通过在主题内部具有并行性概念 - 分区概念,Kafka能够提供订单保证和负载平衡。这是通过将主题中的分区分配给使用者组中的使用者来实现的,以便每个分区仅由组中的一个使用者使用。通过这样做,我们确保消费者是该分区的唯一读者,并按顺序使用这些数据。由于有很多分区,这仍然可以平衡许多消费者实例的负载。但请注意,消费群组中的消费者实例不能多于分区。

    卡夫卡作为存储系统

    任何允许将消息发布出去的消息队列都可以充当存储系统。Kafka的不同之处在于它是一个非常好的存储系统。

    写入Kafka的数据写入磁盘并进行复制以实现容错。Kafka允许生产者等待确认,以便在完全复制之前写入不被认为是完整的,并且即使写入的服务器失败也能保证持续。

    Kafka的磁盘结构使用了很好的规模 - 无论您在服务器上有50 KB还是50 TB的持久性数据,Kafka都会执行相同的操作。

    由于认真考虑存储并允许客户端控制其读取位置,所以可以将Kafka视为专用于高性能,低延迟提交日志存储,复制和传播的专用分布式文件系统。

    有关Kafka提交日志存储和复制设计的详细信息,请阅读页面。

    卡夫卡流处理

    只读取,写入和存储数据流是不够的,目的是启用流的实时处理。

    在Kafka中,流处理器是指从输入主题获取连续数据流,对该输入执行一些处理,并产生连续数据流以输出主题的任何东西。

    例如,零售应用程序可能会接受销售和发货的输入流,并输出一系列重新排序和对这些数据进行计算的价格调整。

    直接使用生产者和消费者API可以做简单的处理。但是对于更复杂的转换,Kafka提供了一个完全集成的Streams API这允许构建应用程序进行非平凡的处理,从而计算聚合关闭流或将流连接在一起。

    这个工具有助于解决这类应用程序面临的难题:处理乱序数据,重新处理代码更改的输入,执行有状态的计算等等。

    流API基于Kafka提供的核心原语构建:它使用生产者和消费者API进行输入,使用Kafka进行有状态存储,并在流处理器实例之间使用相同的组机制来实现容错。

    放在一起

    消息传递,存储和流处理的这种组合看起来很不寻常,但对于Kafka作为一个流媒体平台来说,这是非常重要的。

    像HDFS这样的分布式文件系统允许存储用于批处理的静态文件。有效地,这样的系统允许存储和处理过去的历史数据。

    传统的企业消息传递系统允许处理将来订阅的消息。以这种方式构建的应用程序在到达时处理将来的数据。

    Kafka结合了这两种功能,并且这两种组合对于Kafka用作流式传输应用程序平台和流式传输数据管道都是至关重要的。

    通过将存储和低延迟订阅相结合,流式应用程序可以同样的方式处理过去和未来的数据。这是一个单一的应用程序可以处理历史,存储的数据,而不是结束,当它达到最后一个记录,它可以继续处理未来的数据到达。这是流处理的概括概念,包括批处理以及消息驱动的应用程序。

    同样,对于流式传输数据流水线,订阅实时事件的组合使得可以将Kafka用于非常低延迟的流水线; 但是可靠地存储数据的能力可以将其用于必须保证数据交付的关键数据,或者与只能定期加载数据的离线系统集成,或者可能长时间停机进行维护。流处理设施可以在数据到达时进行转换。



    Kafka的用途:(官网翻译)

    消息

    卡夫卡可以很好地替代传统的信息经纪人。消息代理被用于各种原因(将数据处理与数据生成器分离,缓冲未处理的消息等)。与大多数消息传递系统相比,Kafka具有更好的吞吐量,内置的分区,复制和容错能力,使其成为大型消息处理应用的一个很好的解决方案。

    根据我们的经验,消息传递的使用往往是相对较低的吞吐量,但可能需要较低的端到端延迟,并且通常取决于Kafka提供的强大的持久性保证。

    在这个领域,Kafka与传统的消息系统(如ActiveMQ或 RabbitMQ)相当

    网站活动跟踪

    Kafka的原始用例是能够将用户活动跟踪管道重建为一组实时发布 - 订阅订阅源。这意味着网站活动(用户可能采用的网页浏览量,搜索或其他操作)将发布到每个活动类型一个主题的中心主题。这些订阅源可用于订阅各种用例,包括实时处理,实时监控,加载到Hadoop或离线数据仓库系统以进行离线处理和报告。

    活动跟踪通常是非常高的量,因为为每个用户页面视图生成许多活动消息。

    度量

    卡夫卡通常用于运行监控数据。这涉及从分布式应用程序汇总统计数据以生成操作数据的集中式源。

    日志聚合

    许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器收集物理日志文件,并将其置于中央位置(可能是文件服务器或HDFS)进行处理。Kafka提取文件的细节,并将日志或事件数据作为消息流进行更清晰的抽象。这样可以实现更低延迟的处理,并且更容易支持多个数据源和分布式数据消耗。与Scribe或Flume等以日志为中心的系统相比,Kafka提供同样出色的性能,由复制产生的更强大的持久性保证以及更低的端到端延迟。

    流处理

    Kafka的许多用户在处理管道中处理数据,这些数据由多个阶段组成,其中原始输入数据从Kafka主题中消耗,然后聚合,丰富或以其他方式转化为新的主题,以供进一步消费或后续处理。例如,用于推荐新闻文章的处理流水线可以从RSS提要抓取文章内容并将其发布到“文章”主题; 进一步的处理可以对这个内容进行归一化或者重复删除,并且将已清理的文章内容发布到新的主题; 最终处理阶段可能会尝试将这些内容推荐给用户。这种处理流水线基于各个主题创建实时数据流的图表。从0.10.0.0开始,这是一个轻量但功能强大的流处理库,称为 Kafka Streams  在Apache Kafka中可用于执行如上所述的数据处理。除了Kafka Streams之外,替代性的开源流处理工具还包括 Apache Storm 和  Apache Samza

    事件采购

    事件源 是应用程序设计的一种风格,其中状态更改以时间排序的记录序列进行记录。Kafka对非常大的存储日志数据的支持使得它成为以这种风格构建的应用程序的优秀后端。

    提交日志

    Kafka可以作为分布式系统的一种外部提交日志。日志有助于复制节点之间的数据,并作为失败节点恢复数据的重新同步机制。Kafka中日志压缩功能有助于支持这种用法。在这个用法中,Kafka与Apache BookKeeper项目类似


    1、下载并解压

    > tar -xzf kafka_2.10-0.8.1.1tgz
    > cd kafka_2.10-0.8.1.1

    2、启动服务器

    Kafka使用ZooKeeper,因此如果您还没有ZooKeeper服务器,则需要先启动ZooKeeper服务器。您可以使用与kafka一起打包的便捷脚本来获取快速而简单的单节点ZooKeeper实例。

    bin/zookeeper-server-start.sh config/zookeeper.properties


    现在另起一个终端启动Kafka服务器:

    bin/kafka-server-start.sh config/server.properties



    3、另起一个窗口创建一个主题

    我们用一个分区和一个副本创建一个名为“test”的主题

    bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

    我们现在可以看到这个话题,如果我们运行列表主题命令:

    bin/kafka-topics.sh --list --zookeeper localhost:2181



    4、发送一些消息

    Kafka带有一个命令行客户端,它将从文件或标准输入中获取输入,并将其作为消息发送到Kafka集群。默认情况下,每行将作为单独的消息发送。

    运行生产者,然后在控制台输入一些消息发送到服务器。

    bin /kafka-console-producer .sh --broker-list localhost:9092 --topic test


    5、启动两个用户

    卡夫卡也有一个命令行消费者,将消息转储到标准输出。

    bin/kafka-console-consumer.sh  --zookeeper localhost:2181   localhost:9092 --topic test --from-beginning






    展开全文
  • 范式 1NF属性不可再分割,符合原子性。没什么好解释的,地球人都明白 第二范式 2NF在1NF的基础上:不允许出现有field部分依赖于主键(或者说依赖于主键的一部分)官方说法:数据库表中不存在非关键字段对任一...
  • SPI、I2C、UART种串行总线的原理、区别及应用

    万次阅读 多人点赞 2013-04-24 16:11:38
     如果用通用IO口模拟SPI总线,必须要有个输出口(SDO),个输入口(SDI),另个口视实现的设备类型而定,如果要实现主从设备,需输入输出口,若只实现主设备,需输出口即可,若只实现从设备,只需输入口...
  • java消息机制

    万次阅读 2012-08-18 22:00:28
    1、问: 什么是 Java 消息服务?...是 Java 2 Platform, Enterprise(J2EE)的一部分。 2、目前流行的消息传送产品有哪些? 答:目前流行的有ActiveMQ、IBM WebSphere MQ、SonicMQ等 3、什么时候
  • FreeRTOS是个迷你的...FreeRTOS的代码可以分解为个主要区块:任务,通讯和硬件接口,实现任务管理、时间管理、信号量、消息队列、内存管理、记录功能等功能。 主要讲讲任务和消息队列   1.任务控制模块(TCB)
  • RabbitMQ消息确认机制

    万次阅读 2020-06-03 19:10:43
    在使用RabbitMQ的时候,我们可以通过消息持久化操作来解决因为服务器的异常奔溃导致的消息丢失,除此之外我们还会遇到个问题,当消息的发布者在将消息发送出去之后,消息到底有没有正确到达broker代理服务器呢?...
  • 消息队列使用的四种场景介绍

    万次阅读 多人点赞 2017-04-18 10:55:09
    消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题 实现高性能,高可用,伸缩和最终一致性架构 使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ ...
  • 实体鉴别GB/T 15843研究(合集)

    万次阅读 2018-10-31 22:07:50
    GB/T 15843.2-2008 第2部分:采用对称加密算法的机制;GB/T 15843.3-2008 第3部分:采用数字签名技术的机制;GB/T 15843.4-2008第4部分:采用密码校验函数的机制;GB/T 15843.5-2005 第5部分:使用...
  • Java进阶(四十)线程与进程的区别

    万次阅读 多人点赞 2016-09-28 08:50:07
    Java进阶(四十)线程与进程的区别1、线程的基本概念  概念:线程是进程中执行运算的最小单位,是进程中的个实体,是被系统独立调度和分派的基本单位,线程自己不拥有系统资源,只拥有一点在运行中必不可少的...
  • 在设计与操作维护数据库时,最关键的问题就是要确保数据能够正确地分布到数据库的表中。使用正确的数据结构,不仅...泛化时在识别数据库中的个数据元素、关系以及定义所需的表和各表中的项目这些初始工作之后的个细
  • MQ消息中间件技术

    万次阅读 多人点赞 2016-03-30 14:46:14
    消息是MQ中最小的概念,本质上就是段数据,它能被个或者多个应用程序所理解,是应用程序之间传递的信息载体。
  • 消息队列常见的几种使用场景介绍!

    万次阅读 多人点赞 2018-06-29 19:58:00
    、简介消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能、高可用、伸缩和最终一致性架构。使用较多的消息队列有ActiveM...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,160,355
精华内容 464,142
关键字:

一则消息通常不可少的三部分是