• 关于

    中小企业小程序模式同时通信

    的搜索结果

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C
auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

问题

围绕着内存数据库的4个流言

摘要:Yiftach 表示,历经数年,内存数据库的稳定性已得到了长足的发展,开发者应该理智地看待这个领域所存在的流言,比如内存计算是不可靠和不一致等。 【编者按】作者 ...
sunny夏筱 2019-12-01 21:46:19 7513 浏览量 回答数 3

问题

围绕着内存数据库的4个流言

摘要:Yiftach 表示,历经数年,内存数据库的稳定性已得到了长足的发展,开发者应该理智地看待这个领域所存在的流言,比如内存计算是不可靠和不一致等。 【编者按】作者...
doudou1 2019-12-01 21:17:05 9279 浏览量 回答数 0

回答

“求知若饥,虚心若愚”——这个原本出自《全球概览》的俳句,因为乔布斯在斯坦福大学毕业演讲中的引用而备受推崇,流传成为 IT 界的至理名言之一。在编程界,亦有“代码胜于雄辩”、“Done is better than perfect”等警句,寥寥数语将编程工作者的形象特质描摹到了极致。程序员,就是技术至上、唯代码是瞻且必须不断武装自己的群体。 21 世纪,高薪、高端、高技术范儿已成为程序员的固有标签,在这个新的元年,CSDN 将基于一年一度的开发者大调查数据,以全新的视角深入发掘中国开发者群体的整体现状、应用开发技术以及开发工具/平台的发展趋势,呈现更真实、更全面且更有学习价值的开发者画像。 30 岁以下开发者人数占比超八成,全国有 19.6% 开发者月薪超过 1.7 万元; 六成开发者在使用 Java 语言,近五成开发者近期最想学 Python 语言; Spark、Redis 和 Kafka 正在成为企业大数据平台通用技术组件; 区块链技术近两年是热点,比特币和以太坊是两种主流的区块链开发平台; 人工智能技术日益受到企业和市场的关注,但 64% 企业尚未实现智能化,机器学习/深度学习算法工程师最为急缺; 近七成开发者认为未来 5G 网络的传输速率能达到 4G 网络的 10 倍以上; Apache 项目和 Linux 是开发者较为喜欢的开源项目; 半数开发者很少参与开源项目的开发、维护、运营和社区发展等。 软件开发准入门槛持续降低,近 2 成开发者月薪超过 1.7 万 30 岁以下开发者人数占比超八成,软件开发从业门槛持续降低 从 2015 年到 2019 年的调研数据来看:30 岁及以下的开发者人群占比在 8 成以上,一直是软件开发领域的主力军;全国近半数的开发者工作在一线城市(北京、上海、广州、深圳、天津);物联网、软件、IT 制造三个技术领域涵盖了国内 84% 以上的开发者;本科及以上学历占 8 成;92% 的开发者是男性。 和国外开发者年龄分布趋势大概一致,国内的软件开发群体一直呈现出越来越年轻化的特点。这是因为,一方面软件开发行业蓬勃发展,各行各业都需要软件开发相关人才,也有越来越多的毕业生选择从事该行业;另一方面,是因为编程语言、框架、云服务等基础设施的持续完善,从事软件开发的门槛在持续降低,更容易接纳新鲜血液,报告统计发现,本科学历是开发者的主力军,66% 的开发者拥有本科学历,而硕士研究生、博士研究生仅占 11%、1%。 八成以上开发者月薪在 5 千~3 万元之间,19.6% 开发者月薪超过 1.7 万元 通过结合受教育程度和薪资水平的数据特点来看,学历越高的人群中,月薪 1.7 万元以上的高收入比例越高。在一线城市(北京、上海、广州、深圳、天津)中,月薪超过 1.7 万元的开发者占比为 30%,该比例远高于国内其它城市。 开发者属于相对高薪的职业,尤其是在一线城市中,但不同开发者之间收入差距较大。软件开发是一个智力密集型的工作,不同开发者能够提供的价值差别很大,这就使得一个优秀开发者的收入远高于普通开发者:硕士和博士毕业的高收入者比率要远高于本科及以下的;金融和互联网行业的高收入比率最高。 自学是开发者持续学习的主要路径 软件开发行业日新月异,只有保持持续学习才能跟上技术变化的脚步,终身学习是现代人保持竞争力甚至是维持生存的必要手段。 从调研中可以看到,53% 的开发者会通过在未参加正式课程的情况下,自学一门新语言、框架或工具。但同时,也有半数的人参加过在职培训或者线下课程,相对于自学的灵活性而言,这类培训会更为系统和完整,对于长期的个人提升有所裨益,开发者可以适当选择。但与之相悖的是,只有不到 40% 的开发者,愿意为学习付费,这可能会导致参与的课程质量不够高。 Java 雄踞语言榜,Visual Studio 受开发者欢迎 Java 长盛:使用最多,开发者最想学 从编程语言来看,Java 是最多人使用的语言,而 JavaScript 和 SQL 分别是第二第三位。这三门语言,使用场景都很广泛,Java 一方面后端开发最常使用,生态成熟度无人可比;另一方面,Java 依然是 Android 上最重要的开发语言,与之相比 ,新兴的 Kotlin 只有 2% 的开发者在使用。而 JavaScript 不仅是前端开发的必备语言,还用在 Web 开发、小程序开发等场景下。 Java 和 Python 依然是开发者最希望学习的语言之一,只是相比之下,Python 的热度有所降低,这可能和机器学习没有去年那么火热有所关联。变化比较大的是 Go 语言,与去年相比,今年的调研中想学 Go 语言的开发者降低到了 4%,与之相似,Kotlin、R 的学习意愿也大幅降低。 从这个趋势也可以看到,如今的开发者更意愿去学习一些相对成熟度、用途更为广泛的语言,对一些代表新模式的语言乐衷程度有所降低。 七成以上在使用 Windows 操作系统,83% 在使用 MySQL 数据库 72% 开发者在使用 Windows 操作系统,18% 在使用 Linux 系列操作系统。在存储服务的使用上,MySQL 继续扩大其使用率到达了 83%,几乎是开发者必备的技能。和去年相比,Elasticsearch 出现在数据库使用的调研中,在大数据时代,Elasticsearch 作为提供搜索服务的第一选型,也必然会被越来越多的开发者学习和使用 Node.js 是相对使用普遍的技术框架 在 Web 开发上,前端使用 Vue.js 后端使用 Spring 是最常见的选型方案,与之相对应,Node.js 是最多被用到的框架,这和当今多端开发的趋势密不可分。后端用微服务架构,中间用 Node.js 粘合出适合 Web、Android、iOS 等不同端和场景使用的 APIs,是当下主流的部署方案之一,既可以前后端分离提高开发效率,又可以在保障服务稳定性的同时提升灵活性。而TensorFlow 成为开发者最期望学习的框架,这说明开发者依然对机器学习保持关注和热情。 Visual Studio 是最为普遍使用的开发环境 在开发环境的选择上,Visual Studio 是最为普遍使用的开发环境,这和微软对开发者的投入密不可分。微软投入了大量的研发力量,使得 Visual Studio 可以在各种操作系统进行各种编程语言的开发,其强大且完善的插件系统可以满足开发者的各种需求,使其可以超过 IntelliJ。 大数据平台以私有云部署为主,Spark 使用率高达 44% 私有云部署解决方案是企业构建大数据平台的主要方式 随着分布式计算和云平台的逐步成熟,目前大部分公司都有能力搭建自己的大数据平台。调研数据显示,81% 企业在进行大数据相关的开发和应用,50% 的企业选择私有云解决方案来部署大数据应用,28% 的企业选择自主研发。 仅 19% 企业使用商业发行版 Hadoop 版本搭建数据平台 调查报告发现,有 30% 以上的企业并没有使用相对成熟的 Hadoop 技术搭建数据平台,这些企业的算法性能会很大程度上受限于低效的平台,更不可能开发出更高效的数据分析算法。但幸运的是大部分企业都基于商业版或者社区版 Hadoop 搭建了数据平台,这些公司的侧重点主要在应用发现和算法的设计层面,更有可能在不久的将来实现大数据的价值。 Spark 是企业大数据平台最普遍的组件 Apache Spark 是一个处理大规模数据的快速通用引擎,它可以独立运行,也可以在 Hadoop、Mesos、云端运行,它可以访问各种数据源包括 HDFS、Cassandra、HBase 和 S3,可以提升 Hadoop 集群中的应用在内存和磁盘上的运行速度。Spark 生态系统中除了核心 API 之外,还包括其他附加库,可以为大数据分析和机器学习领域提供更多的能力。本次调研中,Spark 是使用最普遍的大数据平台组件,使用率达到44%,而MapReduce使用率仅为21%。 分布式文件系统 HDFS 作为核心组件之一,使用率也达到了 39%。企业对大数据平台应用最多的场景是统计分析、报表生成及数据可视化,38% 企业使用ELK(ElasticSearch + Logstash + Kibana)实时日志分析平台。 综上所述,目前大数据的发展热潮令人欢欣鼓舞。一个优秀的大数据团队,需要有对产品开发具有高敏感性同时对技术有一定理解的人才,同时需要理论基础极其扎实,能对实际问题进行抽象建模和算法设计的人才。只有双管齐下,在产品和技术方面进行深层次探索,才能真正实现大数据产业的繁荣。 区块链质变,比特币逆袭以太坊成 TOP 1 开发平台 22% 的开发者正在用或者准备用区块链技术解决技术问题 区块链技术的发展,是一个量变到质变的过程。相比于 2018 年,对区块链和加密货币了解的人从 22% 增长到 32%,准备尝试用区块链技术解决一些问题的人数从 14% 增长到 16%,仅有 4% 的人对区块链完全不了解。 43% 的受访者在从事公有链(比特币、以太坊等)的开发 本次调研中,43% 的受访者在从事公有链(比特币、以太坊等)的开发。目前行业侧重发展的方向为解决方案、公链及联盟链,公有链由于其自带激励机制,对于普通开发者有直接的回馈,所以上面开发者占比高也比较合情理。行业解决方案从去年的 27% 增加到今年的 36%,说明传统行业开发者对区块链的认可度在增加。 区块链本质上是技术,落地场景及实际应用才是连接社会效益的关键。 比特币和以太坊是当前两种主流的区块链开发平台 在行业开发者的印象中,以太坊一直是开发平台领域的头号玩家。但今年数据显示,以太坊从 2018 年的 44% 占比第一,降到 24%;比特币从 2018 年的 28%,上升到 35%,占比第一。比特币在行业内外仍然拥有最强共识,在闪电网络的加持下,大家也似乎感受到比特币离商用也不再遥远了。 金融是普遍认为的行业应用方向 金融行业是普遍认为的行业应用方向,占 36%。区块链本身具备的防篡改、可追溯的特点,能大大降低金融行业监管成本,不过金融的进入门槛相对也较高,需要各方面技术的配合。其次,智能硬件和物联网也被认为是主流应用方向,占 14%。不过相比其他众多已经很成熟的技术,依托区块链的解决方案在实际使用中,往往面临必要性缺失的问题,因此区块链应用发展仍任重道远。 在区块链结合行业之前,更加要重视与其他新技术的结合和协同:物联网设备能够提供大量数据,5G 能够提供高速传输,存储可以解决区块存放的问题等。 算法工程师最急缺,TensorFlow 占据 AI 深度学习框架榜首 64% 的企业尚未实现智能化 在经历了 2019 年的行业低谷期之后,无论是行业巨头还是新兴独角兽,都开始审视 AI 能够切实落地的场景。调研数据显示,14% 的企业尚无信息化基础,27% 的企业实现了事务处理数字化,22% 的企业具备商业智能基础设施,实现描述性分析。使用机器学习实现预测性分析和决策优化的企业占 16%,而在业务中全面使用 机器学习/深度学习算法工程师最急缺 在岗位分布上,由于深度学习是以大数据为基础的,而感知智能中的计算机视觉又是目前深度学习较为成熟的应用,所以,机器学习和深度学习工程师,以及数据工程师、计算机视觉工程师排行在前三位。当前最急缺的岗位也是机器学习/深度学习算法工程师、数据科学家/数据分析师/数据挖掘工程师岗位。 53% 的开发者表示其团队急缺机器学习/深度学习算法工程师,37% 表示急缺数据科学家/数据分析师/数据挖掘工程师。 TensorFlow是人工智能领域主流深度学习框架 此次调研中,TensorFlow 使用普及率达到 48%。从技术本身的角度来看,较为成熟的 TensorFlow 成为 AI 工程师的首选深度学习框架,Torch/PyTorch由于其开发效率较高,也得到了较多支持。 35% 开发者选用国产 AI 芯片应用于自己的 AI 开发 在 AI 芯片领域,国内厂商也开始弯道超车,越来越多的开发者也开始关注国内 AI 芯片的进展。调查数据显示,选用国产 AI 芯片应用于自己的 AI 开发时最看重的因素方面,对主流 AI 框架的支持能力是最普遍的因素,占 35%。 物联网云平台三足鼎立:阿里物联、华为云、百度 IoT 69% 的开发者认为未来 5G 网络的传输速率能达到 4G 的 10 倍以上 每一代新型的通信系统总是能带来更大的带宽。据报告显示,近七成开发者认为未来 5G 网络的传输速率能够达到 4G 网络的 10 倍以上。 影响 5G 普及的三大因素:5G 套餐价格未定、运营商的开发程度、需要更换手机 由于目前 5G 网络使用者较少,费用较低廉的套餐还没有推出,第一代 5G 终端不太成熟等原因,目前 87% 的开发者认为 5G 套餐费用过高,并且大部分开发者认为 5G 网络目前覆盖范围有限,因此将近 40% 的开发者正处于观望阶段。 值得一提的是,本次调查中 62% 的开发者认为,5G 时代应该加强对个人隐私的保护,这反映出目前社会对数据隐私越来越重视的整体趋势。 阿里物联和华为云是应用相对普遍的 IoT 云平台 根据调查,2019 年物联网云平台呈现三足鼎立的趋势:阿里物联、华为云、百度 IoT 成为用户最多的三种物联网平台,并且和第四名中移物联远远拉开了差距,这和我们的实际使用体验一致。 未来的基础物联网平台可能会继续呈现以偏硬件实现为主的华为云和以偏软件体验为主的阿里、百度物联平台的三足鼎立局面。 物联网技术开发:Linux 和 Windows 是使用较多的操作系统 Linux 和 Windows 是较普遍的操作系统,使用率分别为 51%、44%。目前在物联网设备开发过程中,Linux、Windows 和 Android 较为普遍,依然延续了 PC 平台的开发者操作系统份额。虽然华为、阿里等公司在 2019 年均发布了自己的物联网专用操作系统,但还并未得到开发者的大规模认可,大公司的物联网操作系统发展之路依然任重而道远。 Wi-Fi 是应用最普遍的物联网通信技术 在本次调研中,近距离通信(比如 Wi-Fi 和蓝牙)是现存物联网开发者最主要的通信方式。然而这种比重可能会随着未来 3~4 年内车联网的大规模商业化产生变化,汽车、工业物联、智能电网这类高移动性、高可靠和低延迟物联网场景会更适合需要整体规划的运营商网络。 六成开源开发者无收入,Apache 项目最受喜欢 77% 开发者每周在开源上投入时间不超过 5 小时 无论是大数据、区块链、人工智能还是物联网领域,其中最为重要的、最受欢迎的技术都是开源的。但是报告统计发现,有超过一半的开发者很少参与开源项目,每周在开源上投入不超过 5 小时的占 77%,其中,1 小时以内的占 31%。此外,65% 的开发者不曾在开源上获得收入,获得不错收入的仅占一成。 开发者最喜欢的开源项目是 Apache 25% 开发者最喜欢 Apache,24% 开发者最喜欢 Linux。作为全球最大的软件基金会,开发者用过的诸多项目,例如 Dubbo、Log4j、Maven、RocketMQ 和 Tomcat 等,均孵化自 Apache。 国内开源的现状虽然近年来已经有了很大的发展,但是一个残酷的事实是,老兵正在离开这个行业,离开一线开发的队伍:报告数据显示,30 岁以下的开发者人数超过 82%,接触开源的时间在 5 年以内的开发者超过 83%。随着那些经验丰富的老兵转行或是进入管理层,不再写代码、也不再参与开源的事实也就凸显出来.....未来开源的建设,依然任重而道远。 在数据中寻找共性,《2019 - 2020 中国开发者调查报告》全面且真实地展现中国开发者及技术现状,希望对您的学习或工作有所帮助。 ———————————————— 版权声明:本文为CSDN博主「CSDN资讯」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/csdnnews/article/details/104538091
问问小秘 2020-03-11 16:46:19 0 浏览量 回答数 0

问题

云服务器ECS下的FTP服务的如何安装配置与使用

简介 FTP 是File Transfer Protocol(文件传输协议)的英文简称,而中文简称为“文传协议”。用于Internet上的控制文件的双向传输。同时,它也是一个应用程...
boxti 2019-12-01 21:45:58 5158 浏览量 回答数 2

问题

【精品问答】Java技术1000问(1)

为了方便Java开发者快速找到相关技术问题和答案,开发者社区策划了Java技术1000问内容,包含最基础的如何学Java、实践中遇到的技术问题、RocketMQ面试、Java容器部署实践等维度内容。 我们会以每...
问问小秘 2019-12-01 21:57:43 46087 浏览量 回答数 16

回答

教程资源类 freeCodeCamp/freeCodeCamp 免费代码训练营 EbookFoundation/free-programming-book 免费编程图书 sindresorhus/awesome awesome 列表的列表。这个项目起源于某个人做了一个 awesome-php 的 php 优质资源 列表,然后大家就做了 awesome-python,awesome-vue 等各种列表,这个项目又把 各种 awesome 列表收集了起来。 CyC2018/CS-Notes 国人编写的计算机基础教程,中文 jwasham/coding-interview-university 面试考点总结 h5bp/Front-end-Developer-Interview-Questions 前端工程师面试问题 vinta/awesome-python Python 的一些优质资源. 前面提到的 awesome 系列列表,不再赘述 airbnb/javascript Airbnb 的 js 编码规范,值得参考。 github/gitignore GitHub 提供的各种项目的 gitignore 文件模板,省了自己写了 getify/You-Dont-Know-JS 前端(JS)的一些坑的总结 vuejs/awesome-vue Vue 的一些优质资源. awesome 系列,不再赘述 前端 UI 框架/库 twbs/bootstrap Twitter 推出的前端 UI 框架,有网格系统和各种组件,曾经常年在 GitHub 上排名第一,可以说是后端工程师画界面的利器。 竞品:Semantic UI, pure-css FontAwesome/Font-Awesome 字体和图标库,可以使用 SVG 和字体等等多种格式。 ant-design/ant-design 蚂蚁金服出的 react/vue 组件库,前一阵大名鼎鼎的“圣诞彩蛋”就是这个库搞得。主要 提供 React 的组件库,用于企业中后端的后台的建设。关于 React/Vue 和前端的组 件化是一个很有意思的话题,可以查阅相关资料。 和 Bootstrap 等的区别在于,Bootstrap 更偏向于 UI 方面,是 CSS 框架,而 antd 则是完整的包括 UI 和功能在内的 React 组件。可以理解为 Bootstrap 只做了“皮”, 而 antd 是 “皮” + “骨”。 Semantic-Org/Sematic-UI 和 Bootstrap 类似的一个组件库。Semantic UI 更强调使用语义化的 class 来定义样式 google / material-design-icons Google 推出的 Material 风格图标库。 daneden/animate.css CSS 动画效果库 大前端框架和库 vuejs/vue Vue 是国人推出的一个前端框架,可以通过写不同的 Vue 组件来组成一个完整的应用, 支持服务端渲染(SSR)。和 React 一样,Vue 也使用了 Virtual-DOM 技术来提高性能。 facebook/react facebook 推出的一个前端框架,特点是每个组件的 HTML/JS/CSS 组合在一起,使用 Virtual-DOM 渲染。在 React 出现之前,前端框架普遍采用了后端广泛使用的 MVC 模式,强调 HTML/JS/CSS 三者要分离,而 React 则反其道而行之,强调从组件构建, 可以说 React 的出现是前端界的一场革命。 facebook/react-native 使用 React 的语法来构建 native app,注意这里并不是使用一个 iOS 或者 Android 的 WebView 中嵌套了一个 webapp,而是直接使用 JS 来操作原生组件。 angular/angular.js Google 推出的前端框架,没用过 reactjs/redux react.js 的一个组件,用来管理数据。 meteor/meteor 前几年火过一阵,号称要统一前后端,然而我从来没搞明白到底是干啥的,如今热度已经 大减了。HN 上甚至直接有人问 Is meteor.js dead? webpack/webpack 用于打包前端资源 chartjs/Chart.js 前端数据可视化组件 electron 可以使用前端的工具链来编写桌面应用,同时能够跨平台。 jQuery 老牌的跨浏览器兼容库。随着浏览器的发展,现在使用 jQuery 的越来越少了。 create-react-app 用来构造 react app 的辅助工具。 d3.js 前端数据可视化组件 后端工具 elasticsearch 使用 Java 编写的一个搜索工具,要实现全文搜索的话,选择 ES 就对了。 moby Docker 的内核. Docker 可以让你打包应用的所有环境, 像虚拟机一样隔离, 但是又不像虚拟机 一样过多消耗资源. 库 ReactiveX/RxJava TODO 一种编程模式,现在还不是很了解。 机器学习 TensorFlow Google 推出的深度学习库, 目前占主流地位. 语言 Microsoft/TypeScript 微软推出的一个 JavaScript 的超集。我们知道 JavaScript 是一个动态弱类型的语言, 这种特性在小项目上很方便,然而随着前端项目越来越大,强类型对于程序正确性的保证 就显得越来越重要了。TypeScript 重点就在于增强了类型,甚至名字都叫 TypeScript。 强类型的语言是近年来语言的发展趋势,新语言诸如 Rust、Go、Swift 都是强类型的 语言。而一些老语言,比如 Python 也加入了 Type Hint 的功能来增强类型支持。 Apple/swift Apple 推出的新语言,用来代替 Obj-C。 golang Google 推出的编程语言。特点是通过 Goroutine 支持高并发。 nodejs 可以在服务器上运行的 js。 通用工具类 hakimel / reveal.js 使用 js 来做 PPT 的一个框架或者说工具 GoogleChrome/puppeteer Google 推出的操作 Chrome 浏览器的 node.js API。可以用在自动化测试和爬虫等领域。 官方 API 的推出基本上意味着第三方工具已经失去意义了。比如说 Phantom.js 直接宣 布停止维护了。 atom GitHub 推出的一个代码编辑器。 oh-my-zsh zsh 的增强组件集,可以让你的 shell 异常强大, 建议刚学命令行的可以体验一下. vscode 微软推出的代码编辑工具,目前占据了市场优势地位。 Web 框架 rails Ruby 的一个 MVC 模式的 web 框架,当年可谓大红大紫,现在似乎热度有所衰减了, 可能是因为大家都不写 Web 应用了。 expressjs Node.js 的一个 Web 框架。 http://socket.io 实现 WebSocket 的一个库,使用 node.js 编写。WebSocket 是在浏览器和服务器之间 实现全双工通信的一个协议。 laravel 一个比较现代的 PHP MVC web 框架,不过 PHP 这几年的热度衰减也很厉害,好多搞 PHP 的都直接转 Go 了。 内核 torvalds/linux 这个不用说了吧。评论里提到 Linux 的贡献者在 GitHub 上显示为正无穷, 厉害了.
有只黑白猫 2020-01-15 16:53:45 0 浏览量 回答数 0

问题

词汇表是什么样的?(S-V)

S A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z SASL ...
轩墨 2019-12-01 22:06:08 2089 浏览量 回答数 0

回答

Kafka 是目前主流的分布式消息引擎及流处理平台,经常用做企业的消息总线、实时数据管道,本文挑选了 Kafka 的几个核心话题,帮助大家快速掌握 Kafka,包括: Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多,本文尽量做到深入浅出,全面的介绍 Kafka 原理及核心组件,不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台,经常用做企业的消息总线、实时数据管道,有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统,目前则演变成了一个成熟的分布式消息引擎,以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式,生产者发送消息到 broker 中某一个 topic 的具体分区里,消费者从一个或多个分区中拉取数据进行消费。拓扑图如下: 目前,Kafka 依靠 Zookeeper 做分布式协调服务,负责存储和管理 Kafka 集群中的元数据信息,包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语: Producer:生产者,消息产生和发送端。 Broker:Kafka 实例,多个 broker 组成一个 Kafka 集群,通常一台机器部署一个 Kafka 实例,一个实例挂了不影响其他实例。 Consumer:消费者,拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组,一条消息只能被消费组中一个 Consumer 消费。 Topic:主题,服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition:topic 的分区,分布式存储在各个 broker 中, 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费,达到消费者高吞吐量。一个分区拥有多个副本(Replica),这是Kafka在可靠性和可用性方面的设计,后面会重点介绍。 message:消息,或称日志消息,是 Kafka 服务端实际存储的数据,每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset:偏移量,分区中的消息位置,由 Kafka 自身维护,Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷(缓冲)、系统解构以及冗余的作用,主要特点有: 高吞吐、低延时:这是 Kafka 显著的特点,Kafka 能够达到百万级的消息吞吐量,延迟可达毫秒级; 持久化存储:Kafka 的消息最终持久化保存在磁盘之上,提供了顺序读写以保证性能,并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展:Kafka 的数据是分布式存储在不同 broker 节点的,以 topic 组织数据并且按 partition 进行分布式存储,整体的扩展性都非常好。 高容错性:集群中任意一个 broker 节点宕机,Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要,这也是 Kafka 高吞吐的基础,生产端的基本流程如下图所示: 主要有以下方面的设计: 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API,新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后,再是经过 Partition 分区器处理,决定消息落到 topic 具体某个分区中,最后把消息发送到客户端的消息缓冲池 accumulator 中,交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制,默认是 32M,当生产消息的速度过快导致 buffer 满了的时候,将阻塞 max.block.ms 时间,超时抛异常,所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch,分批次的发送到 broker 端,批次大小由参数 batch.size 控制,默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端,所以一般减小 batch 大小有利于降低消息延时,增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时,才会批量发送到服务端呢?答案是否定的,Kafka 生产端提供了另一个重要参数 linger.ms,该参数控制了 batch 最大的空闲时间,超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外,Kafka 生产端支持重试机制,对于某些原因导致消息发送失败的,比如网络抖动,开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制,参数含义代表重试次数,默认值为 0 表示不重试,建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本(Replica)的概念,副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本,由 broker 端参数 default.replication.factor 控制,默认值为 1,通常我们会修改该默认值,或者命令行创建 topic 时指定 replication-factor 参数,生产建议设置 3 副本。副本作用主要有两方面: 消息冗余存储,提高 Kafka 数据的可靠性; 提高 Kafka 服务的可用性,follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举,继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区,生产消费端所有的读写请求都是由 leader 副本处理的,follower 副本的主要工作就是从 leader 副本处异步拉取消息,进行消息数据的同步,并不对外提供读写服务。 Kafka 之所以这样设计,主要是为了保证读写一致性,因为副本同步是一个异步的过程,如果当 follower 副本还没完全和 leader 同步时,从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步,引入 ISR(In-Sync Replicas)副本集合的概念,ISR 是分区中正在与 leader 副本进行同步的 replica 列表,且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的,任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的,并不是所有的分区副本都在 ISR 列表中,哪些副本会被包含在 ISR 列表中呢?副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的,参数含义是副本同步落后于 leader 的最大时间间隔,默认10s,意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s,就会被从 ISR 中排除。Kafka 之所以这样设计,主要是为了减少消息丢失,只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举,这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的,所以 ISR 列表就有为空的时候,ISR 为空说明 leader 副本也“挂掉”了,此时 Kafka 就要重新选举出新的 leader。但 ISR 为空,怎么进行 leader 选举呢? Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”,这些副本中的消息远远落后于 leader,如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable,用于控制是否允许非同步副本参与 leader 选举;如果开启,则当 ISR 为空时就会从这些副本中选举新的 leader,这个过程称为 Unclean leader 选举。 前面也提及了,如果开启 Unclean leader 选举,可能会造成数据丢失,但保证了始终有一个 leader 副本对外提供服务;如果禁用 Unclean leader 选举,就会避免数据丢失,但这时分区就会不可用。这就是典型的 CAP 理论,即一个系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)中的两个。所以在这个问题上,Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举,这里建议关闭 Unclean leader 选举,因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器(Controller)是 Kafka 的核心组件,它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色,但在运行过程中,只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper,因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树,ZNode 是 Zookeeper 中的数据节点,是 Zookeeper 存储数据的最小单元,每个 ZNode 可以保存数据,也可以挂载子节点,根节点是 /。基本的拓扑图如下: Zookeeper 有两类 ZNode 节点,分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后,该节点依旧存在,直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起,客户端与 Zookeeper 断开会话后,临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性,它可以在 ZNode 节点上绑定监听事件,比如可以监听节点数据变更、节点删除、子节点状态变更等事件,通过这个事件机制,可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时,都会尝试去 Zookeeper 中创建 /controller 节点,第一个成功创建 /controller 节点的 broker 则会被指定为控制器,其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时,其他 broker 能够快速地感知到,然后再次尝试创建 /controller 节点,创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了,控制器主要作用是管理和协调 Kafka 集群,那么 Kafka 控制器都做了哪些事情呢,具体如下: 主题管理:创建、删除 topic,以及增加 topic 分区等操作都是由控制器执行。 分区重分配:执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作,也是由控制器实现。 Preferred leader 选举:这里有一个概念叫 Preferred replica 即优先副本,表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时,会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理:控制器能够监控新 broker 的增加,broker 的主动关闭与被动宕机,进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制,控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务:控制器上保存了最全的集群元数据信息,其他所有 broker 会定期接收控制器发来的元数据更新请求,从而更新其内存中的缓存数据。 从上面内容我们大概知道,控制器可以说是 Kafka 的心脏,管理和协调着整个 Kafka 集群,因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作,特别是在 0.11 版本中对控制器进行了重构,其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案,消除了多线程的资源消耗和线程安全问题,另外一个改进是把之前同步操作 Zookeeper 改为了异步操作,消除了 Zookeeper 端的性能瓶颈,大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时,提到了消费组的概念,一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组 ,一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言,有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程,在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 的完成。因为要停止消费等待重平衡完成,因此 Rebalance 会严重影响消费端的 TPS,是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance,总结起来有三种情况: 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的,比如为了提高消息吞吐量增加 topic 分区数,这些情况一般是不可避免的,后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前,先来认识下 Kafka 的协调器 Coordinator,和之前 Kafka 控制器类似,Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器: 组协调器(Group Coordinator) 消费者协调器(Consumer Coordinator) Kafka 为了更好的实现消费组成员管理、位移管理,以及 Rebalance 等,broker 服务端引入了组协调器(Group Coordinator),消费端引入了消费者协调器(Consumer Coordinator)。每个 broker 启动的时候,都会创建一个 GroupCoordinator 实例,负责消费组注册、消费者成员记录、offset 等元数据操作,这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外,每个 Consumer 实例化时,同时会创建一个 ConsumerCoordinator 实例,负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理: 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况,一种是有新的消费者加入,通常是我们为了提高消费速度增加了消费者数量,比如增加了消费线程或者多部署了一份消费程序,这种情况可以认为是正常的;另一种是有消费者退出,这种情况多是和我们消费端代码有关,是我们要重点避免的。 正常情况下,每个消费者都会定期向组协调器 Group Coordinator 发送心跳,表明自己还在存活,如果消费者不能及时的发送心跳,组协调器会认为该消费者已经“死”了,就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数:session.timeout.ms 和 heartbeat.interval.ms,含义分别是组协调器认为消费组存活的期限,和消费者发送心跳的时间间隔,其中 heartbeat.interval.ms 默认值是3s,session.timeout.ms 在 0.10.1 版本之前默认 30s,之后默认 10s。另外,0.10.1 版本还有两个值得注意的地方: 从该版本开始,Kafka 维护了单独的心跳线程,之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms,表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔,默认值 5min,对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组,此时将发生一次 Rebalance。 此外,如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿,从而引发 Rebalance。因此,我们总结如何避免消费组 Rebalance 问题,主要从以下几方面入手: 合理配置 session.timeout.ms 和 heartbeat.interval.ms,建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms,通常建议调大避免 Rebalance,但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况,避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数,可以减少生产环境中 Rebalance 发生的几率,提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制,Kafka 控制器、消费端 Rebalance 机制等各方面核心原理,通过本文的介绍,相信你已经对 Kafka 的内核知识有了一定的掌握,更多的 Kafka 原理实践后面有时间再介绍。
剑曼红尘 2020-04-16 18:15:45 0 浏览量 回答数 0

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

阿里极客公益活动: 或许你挑灯夜战只为一道难题 或许你百思不解只求一个答案 或许你绞尽脑汁只因一种未知 那么他们来了,阿里系技术专家来云栖问答为你解答技术难题了 他们用户自己手中的技术来帮助用户成长 本次活动特邀百位阿里技术专家对Java常...
管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19

回答

数据库课程设计 “数据库课程设计”是数据库系统及应用课程的后续实验课,是进一步巩固学生的数据库知识,加强学生的实际动手能力和提高学生综合素质。 一、 课程设计目的 课程设计为学生提供了一个既动手又动脑,独立实践的机会,将课本上的理论知识和实际有机的结合起来,锻炼学生的分析解决实际问题的能力。提高学生适应实际,实践编程的能力。课程设计的目的: 1. 加深对数据库原理、程序设计语言的理论知识的理解和应用水平; 2. 在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高; 3. 学会将知识应用于实际的方法,提高分析和解决问题的能力,增强动手能力; 4. 为毕业设计和以后工作打下必要基础。 二、课程设计要求 运用数据库原理的基本理论与应用知识,在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型,再转换为机器世界的数据模型和数据文件,并对数据文件实施检索、更新和控制等操作。 1. 用E-R图设计选定题目的信息模型; 2. 设计相应的关系模型,确定数据库结构; 3. 分析关系模式各属于第几范式,阐明理由; 4. 设计应用系统的系统结构图,确定系统功能; 5. 通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制; 6. 为参照关系设计插入、删除、修改触发器; 7. 实现应用程序设计、编程、优化功能; 8. 对系统的各个应用程序进行集成和调试,进一步优化系统功能、改善系统用户界面完成实验内容所指定的各项要求; 9. 分析遇到的问题,总结并写出课程设计报告; 10. 自我评价 三、实验环境 开发环境VC++、C#、ASP或JAVA;ODBC/JDBC;数据库SQL Server 四、上机实现内容 1. 创建数据库的结构 2. 创建各基本表的结构 3. 编制系统各功能模块,完成数据的管理(增、删、改)及统计查询。对于程序运行界面不做考核的重点。 五、课程设计考核 1.对学生到实验室的情况进行不定时统计; 2.出勤率+课程设计报告+课程设计所开发的应用系统+其他(上机抽查和提问)=综合评定成绩。 3.课程设计结束时请将下列资料上交: (1) 课程设计报告; (2) 所开发的应用系统的源程序、安装和使用说明; (3) 将(1)(2)中的资料压缩成一个压缩包,压缩包文件的命名规则:班级+学号(末2位)+姓名(例如:计科090101王鹏晓); (4) 班长将本班每人的(3)中的压缩包刻录成光盘连同打印的课程设计报告收齐,交给任课教师。 附录﹑课程设计题目 题目1:课程设计选题管理系统(1,24) 包括三大模块:  课程设计题目维护与查询:题目的添加、修改和删除;按题目类型、名称和关键字查询以及已选与未选题目的查询;  学生信息维护与查询;  学生选题维护与管理:学生选题及查询; 具体功能细化:  前台学生选题:学生上网登录系统进行选题;  前台教师出题:  教师添加、修改和删除题目;  教师确认学生的选题;  后台管理出题和选题  添加用户及权限 题目2:书店管理系统(23) 包括四大模块:  售书(图书销售管理及销售统计,查询)  进书(通过书目,向发行商下定单订购图书)  库存(图书库存,统计)  相关查询 题目3:图书馆管理系统(11) 包括四大模块:  图书的查询  借书  还书  图书的预约 题目4:库存管理系统(8) 包括四大模块:  商品目录建立  商品入库管理  商品出库管理  商品库存查询 题目5:工资管理系统(1 人)41 包括四大模块:  系统数据初始化  员工基本信息数据的输入、修改、删除;  员工个人信息及工资表的查询;  员工工资的计算; 参考数据如下:  员工基本状况:包括员工号、员工姓名、性别、所在部门、工资级别、工资等级等。  工资级别和工资金额:包括工资等级、工资额。  企业部门及工作岗位信息:包括部门名称、工作岗位名称、工作岗位工资等。  工龄和工资金额:包括工龄及对应工资额。  公司福利表:包括福利名称、福利值。  工资信息:包括员工号、员工姓名、员工基础工资、员工岗位工资、员工工龄工资、公司福利、员工实得工资。 题目6:酒店客房管理系统 (1 人)14,26 包括四大模块:  前台操作:包括开房登记、退房结账和房状态查看  预订管理:包括预订房间、预订入住和解除预订  信息查询:包括在住客人列表、预订客人列表和历史客人列表  报表统计:包括开房记录统计、退房结账和预订房间统计  员工基本信息数据的输入、修改、删除; 参考数据如下:  住店管理:客人姓名、证件号码、房号、入住时期、预计离开日期、结账离开日期、应付金额  客人信息:姓名、性别、证件类型、证件号码、联系电话  房间信息:房号、房类型、价格、押金、房状态 预订房间  客人姓名、性别、房类型、房号、价格、证件类型、证件号码、联系电话、入住日期、预计离开日期、历史信息 题目7:旅行社管理信息系统(1 人)3 包括如下模块:  旅游团队、团队团员及旅游路线相关信息的输入  旅游团队、团队团员及旅游路线相关信息的维护(修改、浏览、删除和撤销)  旅游团队管理信息的查询(如按团队编号)  团队团员基本情况的查询(可选多种方式)  旅游路线相关信息的查询(如按线路编号)  旅游路线排行榜发布。  数据备份,更改密码。 参考数据如下:  团员信息表(路线编号,团队编号,团员编号,姓名,性别,电话,通信地址,身份证号码, 团费交否,备注)  线路信息表(路线名称,团费,简介,图形,路线编号)  团队信息表(团队编号,路线编号,团员人数,出发日期,返程日期)  旅游团队信息表(团队编号,团队负责人,团员人数,建团时间,是否出发,团费,盈亏) 密码信息(操作员,密码) 题目8:报刊订阅管理系统 (1 人)25,35 包括如下模块:  登录功能:登录统为身份验证登录。分为管理员登录和一般用户登录。分别通过不 同的用户名和密码进入报刊订阅管理界面,新的用户需要注册。  录入新信息功能:对于管理员,包括新用户信息和新报刊信息的录入功能,信息一旦 提交就存入到后台数据库中;普通用户自行注册进行可以修改个人信息。  订阅功能:用户可以订阅报刊,系统自动计算所需金额,并显示在界面上;管理员不 可订阅报刊,必须以用户身份订阅报刊。  查询功能:用户可以查询并显示自己所订阅的信息;管理员可以按人员、报刊、部门 分类查询。查询出的信息显示在界面上,并且可以预览和打印出结果。  统计功能:管理员可以按用户、部门、报刊统计报刊的销售情况,并对一些重要的订 阅信息进行统计;普通用户可以统计出自己的订阅情况,并且可以预览和打印出结果。  系统维护功能:数据的安全管理,主要是依靠管理员对数据库里的信息进行备份和恢 复,数据库备份后,如果出了什么意外可以恢复数据库到当时备份的状态,这提高了系统和 数据的安全性,有利于系统的维护 参考数据如下:  管理员表(Adminuser) :管理员名、密码。  部门表(Department) :部门号,部门名。  用户表(Users) :用户账号、密码、真实姓名、身 份证号、联系电话,联系地址,部门号(和部门表有关)等。  报刊类别表(NewspaperClass) :分类编号、 分类名称。  报刊信息表(Newspaper) :报刊代号、报刊名称、出版 报社、出版周期、季度报价、内容介绍、分类编号(和报刊类别表有关)等。  订单表(Order) :订单编号、用户编号、报刊代号、订阅份数、订阅月数等。 题目9:计算机等级考试教务管理系统(2 人)32 包括四大模块:  用户设置:对考点代码,考点名称进行设置,设置用户与密码;系统复位:即清除上一次考试数据(在之前存入历史)  报名管理: 报各库录入(姓名不能不空,之间不能有空格) 增加、删除、修改、浏览  准考证管理:准考证生成规则:xxx+yy+zz+kk,其中 XXX 为考点代码;YY 为语言代码,XX 为考场号,KK 为座位号 同一级别、语言应根据报名初始库信息按随机数生成准考证,同一考点最多可有 99*30=2970 名考生;如已生成准考证号,再重新生成准考证号,应该给予提示。 准考证打印  考务管理:考生信息查询、浏览、打印  成绩管理:成绩数据录入、接收 成绩合成(总成绩=笔试成绩*0.6+上机成绩*0.4),按大于或等于 60 合格 参考数据如下:  初始报名表(准考证号(为空) ,报名号(主键) ,级别+语言种类(外键) ,姓名,性别, 出生年份,民族,身份证号,联系地址,联系电话,照片,备注,参加培训)  含准考证号的报名表(准考证号(为主键) ,报名号,级别+语言种类(外键) ,姓名,性别, 出生年份,民族,身份证号,联系地址,联系电话,照片,备注,参加培训)  成绩表(准考证号,笔试成绩,上机成绩,总成绩) 级别语言代码表(级别语言代码,级别+语言)  用户信息表(考点代码,考点名称,用户名,密码) 题目10:人事管理系统(1 人)21 包括四大模块:  登录管理:包括操作员管理,口令设置,权限管理  人员管理:包括人事数据维护、人事信息查询和人事信息统计  工资管理  部门管理:包括部门表,职称表和年份表  查询及报表打印 参考数据如下:  人事表(编号,姓名,性别,出生日期,工作日期,部门代码,职称,婚否,简历,相片)  工资表(基本工资,岗位津贴,奖励,应发工资,水电,保险,实发工资)  部门表(代码,部门名称)  职称表(职称代码,职称名称)  年份表(年份代码,年份名称)  操作员表(操作员代码,操作员姓名,口令,部门,电话) 系统日志表(操作员代号,操作员姓名,登录时间,离开时间) 题目11:商品销售管理系统(1 人)19 包括四大模块:  用户登录  基本信息管理:包括销售情况、商品信息、库存表、员工表等信息的录入、浏览、修改、撤销、删除和查询等  商品销售管理:包括商品售出、退回和入库  盘点:包括库存盘点、当日销售盘点 参考数据如下:  商品信息表(商品编号,商品名称,品牌,型号,销售单价) 商品编号=类别代码(1 位)+品名代码(1 位)+品牌代码(2 位)+型号代码(2 位)  销售情况表(成交编号,商品编号,销售数量,总金额,销售日期,员工编号)  库存表(商品编号,供货商编号,进货日期,进货价,库存数量)  员工表(员工编号,员工姓名,性别,基本工资,职务,密码)  供货商表(供货商编号,供货商名称,所在地,联系电话)  员工资料表(员工编号,员工姓名,是否党员,简历,照片) 题目12:学生成绩管理系统(1 人)29 包括四大模块:  基本数据管理:包括院系管理,专业管理(设置院系下面的专业),班级管理(设置专业下面的班级),课程管理(设置相应专业下面的课程)  学生信息管理:包括基本信息录入、基本信息修改  学生成绩管理:包括学生成绩录入、学生成绩修改  信息查询:包括基本信息查询、成绩信息查询、学校人数统计  系统管理:用户管理、数据备份和系统帮助 参考数据如下:  院系信息(院系代码,院系名称)  院系专业信息(班级、院系代码,专业)  学生基本信息(班号,学号,姓名,性别,出生年月,籍贯,政治面貌,身份证号,入学年月,家庭地址,邮政编码,图片信息,备注)  学生成绩表(学号,课号,成绩,备注)  课程表(课号,课程名称,学期,备注)  班表(班号,班级名称)  用户信息表(用户名,密码,用户标识) 题目13:火车售票管理系统(4 人)36 包括四大模块:  售票管理  订票管理  信息查询  系统维护 参考数据如下:  车次信息表(车次,始发站,终点站,发车时间,到达时间)  订票信息表(车次,座位号,发车时期,发车时间,座位等级,票价)  车次座位等级分配及座位占用表(车次,座位号,座位等级,票价,占用标志)  用户信息表(用户名,密码,用户标识) 题目14:小型物业管理系统(1 人) 包括四大模块:  房源管理:对原始资料的录入、修改、查询和刷新。一般用户可以查询与房间有关 的统计资料;物业主管可其进行增、删、改、插等操作  租房管理:对房产出租,退租以及租房面积调整。其中物业主管可对其进行房租金 额计算和收款操作,一般用户对其查询  水电处理:根据租房资料,结合当月水、电量进行分摊,完成应收水电费。其中物 业主管对其进行计算,其他查询  交款处理:提供收款和发票打印以及交款数据查询  查询处理:对租房资料、交款资料,发票资料进行查询 参考数据如下:  房源资料(名称,面积,月租,物业,仓库)  租房资料(名称,面积,单位,月租,物业,押金,仓库)  水电资料(单位,电量,水量,电费,水费)  交费资料(收费项目,应收日期,应收金额,已收金额,未收金额,本次收款)  发票资料(单位,房租,电费,水费,物业)  权限资料(用户,密码,房源管理,租房管理,水电管理,交费管理,发票管理,系统维护) 其中系统管理员,有权进行系统维护;单位内部物业主管,有权进行物业资源调配、单元出 租,退租和收款开票操作;物业管理员,有权进行水电处理和收款处理等操行;租户代表, 有权进行种类费的查询操作 题目15:机房收费管理系统(1 人)7,34 包括四大模块:  登录模块  上机管理模块 说明:上机登记时,余额不足 3 元或卡处于挂失状态,则拒绝登记 每位同学的一次上机形成一条记录,每 36S 遍历一次上机记录表,对表中所有正上机字段为 TRUE 的记录的上机用时增加 36S,同时从上机卡表的余额减少  上机卡管理模块  充值挂失模块  查找统计模块:统计某天上机的总时数、每次上机的平均时数和机房的收入;某学 生上机的次数、上机总时数、每次上机平均时间;挂失和查询余 参考数据如下:  上机卡(卡号,姓名,专业班级,余额,状态) 状态的取值有:正常(能自费上机)  挂失上机记录(卡号,上机日期,开始时间,上机用时,正上机,管理号代码),上机用时记录学生上机时间(S);正上机是一个布尔型,为 True 表示正上机,每 36 秒刷新 其上机用时并扣除上机费用,为 False 表示上机结束。上机记录表永久保存,用于事后查询 和统计 管理员(代码,姓名,口令)  题目16:高校药房管理(1 人)31 包括四大模块:  基础数据处理:包括医生和药剂师名单的录入,修改,删除及查询  营业数据处理:包括药品进货上柜,处理划价,配药,柜存药品查询,处方综合查 询,交接班结转清。 参考数据如下:  药品信息表(货号,货名,计量单位,进货数量,进货单价,出售单价,进货日期,收货人 和供应商)  处方信息(编号,患者姓名,医生姓名,药剂师姓名,处方日期,配药日期) 处方药品信息(处方编号,药品货号,计量单位,配药数量,销售单价,已配药否)  医生名单和药剂师名单表(姓名)  题目17:考勤管理系统(2 人)40 包括四大模块:  记录每个员工每天所有进入公司的时刻和离开公司的时刻。  每天结束时自动统计当天的工作时间  每天结束时自动统计当天迟到或早退的次数。  对于弹性工作制,每天结束时自动统计当月的工时,并自动算出当月欠缺或富余的 时间  每个月末统计该月的工作时间判断是束足够  每个月末统计该月的工作天数并判断是否足够  管理人员查询并修改工作时间(特殊情况下修改)  管理人员账户管理(如设置密码等)  管理人员设定早退及迟到的条件,每个月的工作时间  管理人员设定每个月的工作日期及放假日期 参考数据如下:  员工信息(工号,姓名,年龄,入职时间,职位,性别,密码)  配置信息(上班时间小时,上班时间分钟,下班时间小时,下班时间分钟,每天工作时间)  每月统计数据表(工号,姓名,剩余的时间,迟到的次数,早退的次数,工作天数)  每天统计信息表(工号,姓名,小时,分钟,动作,时间) 其中动作指的时入或离开公司  题目18:单位房产管理系统(2 人)33,10 包括四大模块:  系统模块:完成数据库维护、系统关闭功能  物业费用模块:完成本月物业的计费、历史资料查询和财务部门接口传送数据、物 业相关费用单价设置  房屋资源模块:对房屋资源进行添加、列表显示、查询  职工信息模块:对职工进行添加、列表显示、查询以及相应部门、职务进行维护  帮助模块:对用户使用本系统提供在线帮助 参考数据如下:  职工(编号,姓名,性别,参加工作时间,行政职务,专业技术职务,评上最高行政职务时 间,评上最高专业技术职务时间,双职工姓名,现居住房号,档案号,房产证号,所在部门 编号,是否为户主)  部门(编号,部门名称) 住房级别表(编号,级别,住房标准,控制标准,级别分类)  房产情况(编号,房号,使用面积,现居住人 id,上一个居住人 id,最早居住人 ID,阳台面积)  物业费用(编号,房号,水基数,水现在值,电基数,电现在值,燃气基数,燃气现在值, 当前年份,当前月份)  价格标准(编号,水单价,电单价,燃气单价) 题目19:标准化考试系统 (2 人)15,39 功能要求: 设计一个简单的标准化考试系统,仅有单项选择题、多项选择题和判断题功能即可。 包括四大模块:  题库管理:实现试题的录入、修改、删除功能;  考试子系统:能够实现考生做题、结果自动存入到数据库中,有时间提示;  选择身份(登录)功能:系统能够记录考生输入的登录信息及交卷信息;  自动评分功能:考生交卷后能自动评分;  查看成绩功能:能够查询考生相关信息(包含成绩等)。 参考数据如下: 其它可供选择的题目: 网上教务评教系统130,127,133 16 学生日常行为评分管理系统232,110,230 网上鲜花店 38 基于BS结构的工艺品销售系统12 基于BS结构的校园二手物品交易网站 37 大学生就业管理系统201,208,234 题库及试卷管理系统 数据库原理及应用 课程设计报告 题目: 课程设计选题管理系统 所在学院: 班 级: 学 号: 姓 名: 李四 指导教师: 2011年12月 日 目录 一、 概述 二、需求分析 三、概念设计 四、逻辑设计 五、系统实现 六、小结 一、概述
玄学酱 2019-12-02 01:22:25 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT