• 关于

    分布式优化有什么用

    的搜索结果

回答

1,架构师是什么?要想往架构师的方向发展首先要知道架构师是什么?架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展,为目标客户提供更为全面的需求清单。架构师在软件开发的整个过程中起着很重要的作用。说的详细一些,架构师就是确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。2,架构师的任务架构师的主要任务不是从事具体的软件程序的编写,而是从事更高层次的开发构架工作。他必须对开发技术非常了解,并且需要有良好的组织管理能力。可以这样说,一个架构师工作的好坏决定了整个软件开发项目的成败。在成为Java架构师之前,应当先成为Java工程师。熟练使用各种框架,并知道它们实现的原理。jvm虚拟机原理、调优,懂得jvm能让你写出性能更好的代码;池技术,什么对象池,连接池,线程池……Java反射技术,写框架必备的技术,遇到有严重的性能问题,替代方案java字节码技术;nio,没什么好说的,值得注意的是"直接内存"的特点,使用场景;java多线程同步异步;java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效的解决问题,比如hashmap的实现原理,好多五年以上经验的人都弄不清楚,还有为什扩容时有性能问题?不弄清楚这些原理,就写不出高效的代码,还会认为自己做的很对;总之一句话,越基础的东西越重要,很多人认为自己会用它们写代码了,其实仅仅是知道如何调用api而已,离会用还差的远。如果你立志做架构,首先打好基础,从最底层开始。然后发展到各种技术和语言,什么都要懂两点,要全面且不肤浅。为什么不是懂一点?你要看得透彻,必须尽量深入一些。别人懂一点,你要做架构师,必须再多懂一点。比如你发现golang很流行,别人可能写一个helloworld就说自己玩过golang,但你至少要尝试写一个完整的应用。不肯下苦功,如何高人一头?另外你要非常深入地了解至少一门语言,如果你的目标是java,就学到极致,作为敲门砖,先吃饱了才能谈理想。3,架构师都是从码农过来的而Java学到极致势必涉及到设计模式,算法和数据结构,多线程,文件及网络IO,数据库及ORM,不一而足。这些概念放之一切语言都适用。先精一门,为全面且不肤浅打基础。另外就是向有经验的架构师学习,和小伙伴们讨论辩论争论。其实最重要的能力就是不断学习。在思考新的技术是否能更好地解决你们遇到的问题之前,你首先得知道并了解新的技术。架构师都是从码农过来的,媳妇熬成婆。千万不要成为不写代码的架构师,有些公司专门产不写技术的架构师。所谓架构师,只是功底深厚的程序员而已。个人认为应该扎扎实实学习基础知识,学习各种规范,架构,需要广泛的知识面,懂的东西越多视野越开阔,设计的东西当然会越好越全面。成为架构师需要时间的积累的,不但要知其然还要知其所以然。平时的一点一滴你感觉不到特别用处,但某天你会发现所有东西都没有白学的。4,架构师知识体系下面是我总结多年经验开发的架构师知识体系一、分布式架构架构分布式的英文( Distributed computing 分布式计算技术)的应用和工具,成熟目前的技术包括 J2EE,CORBA 和 .NET(DCOM),这些技术牵扯的内容非常广,相关的书籍也非常多。本文不介绍这些技术的内容,也没有涉及这些技术的细节,只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。分布式系统是一个古老而宽泛的话题,而近几年因为“大数据”概念的兴起,又焕发出了新的青春与活力。除此之外,分布式系统也是一门理论模型与工程技法。并重的学科内容相比于机器学习这样的研究方向,学习分布式系统的同学往往会感觉:“入门容易,深入难”的确,学习分布式系统几乎不需要太多数学知识。分布式系统是一个复杂且宽泛的研究领域,学习一两门在线课程,看一两本书可能都是不能完全覆盖其所有内容的。总的来说,分布式系统要做的任务就是把多台机器有机的组合,连接起来,让其协同完成一件任务,可以是计算任务,也可以是存储任务。如果一定要给近些年的分布式系统研究做一个分类的话,我个人认为大概可以包括三大部分:分布式存储系统分布式计算系统分布式管理系统二、微服务当前微服务很热,大家都号称在使用微服务架构,但究竟什么是微服务架构?微服务架构是不是发展趋势?对于这些问题,我们都缺乏清楚的认识。为解决单体架构下的各种问题,微服务架构应运而生。与其构建一个臃肿庞大,难以驯服的怪兽,还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一,按照单一责任原则(Single Responsibility Principle)明确角色。将各个服务做轻,从而做到灵活,可复用,亦可根据各个服务自身资源需求,单独布署,单独作横向扩展。微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。概念:把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。定义:围绕业务领域组件来创建应用,这些应用可独立地进行开发,管理和迭代在分散的组件中使用云架构和平台式部署,管理和服务功能,使产品交付变得更加简单。本质:用一些功能比较明确,业务比较精练的服务去解决更大,更实际的问题。三、源码分析从字面意义上来讲,源文件的英文指一个文件,指源代码的集合。源代码则是一组具有特定意义的可以实现特定功能的字符(程序开发代码)。源码分析是一种临界知识,掌握了这种临界知识,能不变应万变,源码分析对于很多人来说很枯燥,生涩难懂。源码阅读,我觉得最核心有三点:技术基础+强烈的求知欲+耐心。我认为是阅读源码的最核心驱动力我见到绝大多数程序员,对学习的态度,基本上就是这几个层次(很偏激哦):1,只关注项目本身,不懂就百度一下。2,除了做好项目,还会阅读和项目有关的技术书籍,看维基百科。3,除了阅读和项目相关的书外,还会阅读IT行业的书,比如学的Java的时,还会去了解函数语言,如LISP。4,找一些开源项目看看,大量试用第三方框架,还会写写演示。5,阅读基础框架,J2EE 规范,调试服务器内核。大多数程序都是第1种,到第5种不光需要浓厚的兴趣,还需要勇气:?我能读懂吗其实,你能够读懂的耐心,真的很重要。因为你极少看到阅读源码的指导性文章或书籍,也没有人要求或建议你读。你读的过程中经常会卡住,而一卡主可能就陷进了迷宫这时,你需要做的,可能是暂时中断一下,再从外围看看它:如API结构,框架的设计图。四、工具使用工欲善其事必先利其器,工具对 Java 的的程序员的重要性不言而喻现在有很多库,实用工具和程序任的 Java 的开发人员选择。下图列出的工具都是程序员必不可少的工具五、性能优化不管是应付前端面试还是改进产品体验,性能优化都是躲不开的话题。优化的目的是让用户有“快”的感受,那如何让用户感受到快呢?加载速度真的很快,用户打开输入网址按下回车立即看到了页面加载速度并没有变快,但用户感觉你的网站很快性能优化取决于多个因素,包括垃圾收集,虚拟机和底层操作系统(OS)设置。有多个工具可供开发人员进行分析和优化时使用,你可以通过阅读爪哇工具的源代码优化和分析来学习和使用它们。必须要明白的是,没有两个应用程序可以使用相同的优化方式,也没有完美的优化的 Java 应用程序的参考路径。使用最佳实践并且坚持采用适当的方式处理性能优化。想要达到真正最高的性能优化,你作为一个 Java 的开发人员,需要对 Java 的虚拟机(JVM)和底层操作系统有正确的理解。性能优化,简而言之,就是在不影响系统运行正确性的前提下,使之运行地更快,完成特定功能所需的时间更短。性能问题永远是永恒的主题之一,而优化则更需要技巧。Java程序员如何学习才能快速入门并精通呢?当真正开始学习的时候难免不知道从哪入手,导致效率低下影响继续学习的信心。但最重要的是不知道哪些技术需要重点掌握,学习时频繁踩坑,最终浪费大量时间,所以有一套实用的视频课程用来跟着学习是非常有必要的。为了让学习变得轻松、高效,今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。这套视频课程详细讲解了(Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构)等这些成为架构师必备的内容!而且还把框架需要用到的各种程序进行了打包,根据基础视频可以让你轻松搭建分布式框架环境,像在企业生产环境一样进行学习和实践。
auto_answer 2019-12-02 01:51:27 0 浏览量 回答数 0

问题

【精品问答】Java专业术语50问

Java作为最流行的语言,一直占据着非常大的市场,但是很多遍Java程序员没有把Java基础的专业知识把握好,所以后期开发遇到问题非常多,下面来看一些Java常见的专业术语知识。 S...
游客pklijor6gytpx 2019-12-01 21:56:07 13032 浏览量 回答数 4

回答

你好,这里有208份资料,详情请参考:https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字,短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库,也是Google的作品。其中介绍了很多一致性方面的设计考虑,为了简单的逻辑设计,还采用了原子钟,同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁,Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的,所以Chubby实际上是Google分布式事务的基础,具有非常高的参考价值。另外,著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper,阐述了一种构建分布式文件系统的范式方法,个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文,此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页,这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori:A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文:设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程,如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例,主要面向大文件和批处理系统, 设计简单而实用。 GFS是google的重要基础设施, 大数据的基石, 也是Hadoop HDFS的参考对象。 主要技术特点包括: 假设硬件故障是常态(容错能力强), 64MB大块, 单Master设计,Lease/链式复制, 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表, 在google内部应用广泛,大数据的奠基作品之一 , Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括: 基于GFS实现数据高可靠, 使用非原地更新技术(LSM树)实现数据修改, 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议, 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题, 能加深对主从强一致复制的理解程度。 技术特点: 支持强一致主从复制协议, 允许多种存储实现, 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法, 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储,还支持表格、队列等数据模型. 主要技术特点:采用Stream/Partition两层设计(类似BigTable);写错(写满)就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用, 是理解Paxo协议及其应用场景的必备论文。 主要技术特点: paxo协议, replicated log, multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点:综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统, 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学,自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念,以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小,但半死不活(网络/磁盘),对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的,其中有两个视频链接,分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书( The Architecture of Open Source Applications)的源代码附录,是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页,没有上课的视频,但是并不影响你跟着它上课:每一周读两篇课程指定的论文,读完之后看lecture-notes里对该论文内容的讨论,回答里面的问题来加深理解,最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后,你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单,逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍:事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法,Lamport在2001发表了《Paxos Made Simple》,以更平直的口头语言描述了Paxos,而没有包含正式的证明和数学术语。《Paxos Made Simple》中,将算法的参与者更细致的划分成了几个角色:Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍:PaxosLease:实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍:Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍:Hadoop学习清单. 《Hadoop Reading List》介绍:Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍:NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍:Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍:Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍:理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍:经典论文 《Programming Languages for Parallel Processing》介绍:并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍:此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍:分布式文件系统综述 《Concepts of Concurrent Programming》介绍:并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍:并发控制性能建模:选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍:ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍:分布式系统设计的形式方法 《互斥和选举算法》介绍:互斥和选举算法 《Actors:A model Of Concurrent Cornputation In Distributed Systems》介绍:经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍:如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍:卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍:Dapper,大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍:伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍:PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍:伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍:MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍:google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍:分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍:分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍:是著名的Ceph的负载平衡策略,文中提出的几种策略都值得尝试,比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍:Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍:对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍:服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍:分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍:加利福尼亚大学的研究生操作系统课程主页,论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍:Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi) 《GraphLab: A New Framework for Parallel Machine Learning》介绍:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟; 《F1: A Distributed SQL Database That Scales》介绍:这篇论文是Google 2013年发表的,介绍了F1的架构思路,13年时就开始支撑Google的AdWords业务,另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍:CockroachDB :一个可伸缩的、跨地域复制的,且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍:Multi-Paxos实现与总结,此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example,地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍:一致性协议zab分析 《A Distributed Hash Table》介绍:分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍:分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍:分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍:闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍:微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍:虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍:Linux B-tree文件系统. 《Akamai technical publication》介绍:Akamai是全球最大的云计算机平台之一,承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文,先看论文领会思想,然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍:来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍:Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”,这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中,作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”,特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”: “对于某个应用来说,无论它的部署环境如何,总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关,在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍:分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍:Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍:SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源(可下载) 《Anatomy of a database system》介绍:数据库系统剖析,这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程(Concurrency Programming)资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议,我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文,面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers(updated Spring 2015)列举出来,可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的,然后通过Google找到了这一篇关于缓存策略的论文,它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透,分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识?》介绍:[怎么学系列]学习分布式系统需要怎样的知识? 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组,他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录,但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文,涉及分布式系统设计,性能分析,实践,优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文,学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.
suonayi 2019-12-02 03:17:27 0 浏览量 回答数 0

回答

一、基础篇 1.1、Java基础 面向对象的特征:继承、封装和多态 final, finally, finalize 的区别 Exception、Error、运行时异常与一般异常有何异同 请写出5种常见到的runtime exception int 和 Integer 有什么区别,Integer的值缓存范围 包装类,装箱和拆箱 String、StringBuilder、StringBuffer 重载和重写的区别 抽象类和接口有什么区别 说说反射的用途及实现 说说自定义注解的场景及实现 HTTP请求的GET与POST方式的区别 Session与Cookie区别 列出自己常用的JDK包 MVC设计思想 equals与==的区别 hashCode和equals方法的区别与联系 什么是Java序列化和反序列化,如何实现Java序列化?或者请解释Serializable 接口的作用 Object类中常见的方法,为什么wait notify会放在Object里边? Java的平台无关性如何体现出来的 JDK和JRE的区别 Java 8有哪些新特性 1.2、Java常见集合 List 和 Set 区别 Set和hashCode以及equals方法的联系 List 和 Map 区别 Arraylist 与 LinkedList 区别 ArrayList 与 Vector 区别 HashMap 和 Hashtable 的区别 HashSet 和 HashMap 区别 HashMap 和 ConcurrentHashMap 的区别 HashMap 的工作原理及代码实现,什么时候用到红黑树 多线程情况下HashMap死循环的问题 HashMap出现Hash DOS攻击的问题 ConcurrentHashMap 的工作原理及代码实现,如何统计所有的元素个数 手写简单的HashMap 看过那些Java集合类的源码 1.3、进程和线程 线程和进程的概念、并行和并发的概念 创建线程的方式及实现 进程间通信的方式 说说 CountDownLatch、CyclicBarrier 原理和区别 说说 Semaphore 原理 说说 Exchanger 原理 ThreadLocal 原理分析,ThreadLocal为什么会出现OOM,出现的深层次原理 讲讲线程池的实现原理 线程池的几种实现方式 线程的生命周期,状态是如何转移的 可参考:《Java多线程编程核心技术》 1.4、锁机制 说说线程安全问题,什么是线程安全,如何保证线程安全 重入锁的概念,重入锁为什么可以防止死锁 产生死锁的四个条件(互斥、请求与保持、不剥夺、循环等待) 如何检查死锁(通过jConsole检查死锁) volatile 实现原理(禁止指令重排、刷新内存) synchronized 实现原理(对象监视器) synchronized 与 lock 的区别 AQS同步队列 CAS无锁的概念、乐观锁和悲观锁 常见的原子操作类 什么是ABA问题,出现ABA问题JDK是如何解决的 乐观锁的业务场景及实现方式 Java 8并法包下常见的并发类 偏向锁、轻量级锁、重量级锁、自旋锁的概念 可参考:《Java多线程编程核心技术》 1.5、JVM JVM运行时内存区域划分 内存溢出OOM和堆栈溢出SOE的示例及原因、如何排查与解决 如何判断对象是否可以回收或存活 常见的GC回收算法及其含义 常见的JVM性能监控和故障处理工具类:jps、jstat、jmap、jinfo、jconsole等 JVM如何设置参数 JVM性能调优 类加载器、双亲委派模型、一个类的生命周期、类是如何加载到JVM中的 类加载的过程:加载、验证、准备、解析、初始化 强引用、软引用、弱引用、虚引用 Java内存模型JMM 1.6、设计模式 常见的设计模式 设计模式的的六大原则及其含义 常见的单例模式以及各种实现方式的优缺点,哪一种最好,手写常见的单利模式 设计模式在实际场景中的应用 Spring中用到了哪些设计模式 MyBatis中用到了哪些设计模式 你项目中有使用哪些设计模式 说说常用开源框架中设计模式使用分析 动态代理很重要!!! 1.7、数据结构 树(二叉查找树、平衡二叉树、红黑树、B树、B+树) 深度有限算法、广度优先算法 克鲁斯卡尔算法、普林母算法、迪克拉斯算法 什么是一致性Hash及其原理、Hash环问题 常见的排序算法和查找算法:快排、折半查找、堆排序等 1.8、网络/IO基础 BIO、NIO、AIO的概念 什么是长连接和短连接 Http1.0和2.0相比有什么区别,可参考《Http 2.0》 Https的基本概念 三次握手和四次挥手、为什么挥手需要四次 从游览器中输入URL到页面加载的发生了什么?可参考《从输入URL到页面加载发生了什么》 二、数据存储和消息队列 2.1、数据库 MySQL 索引使用的注意事项 DDL、DML、DCL分别指什么 explain命令 left join,right join,inner join 数据库事物ACID(原子性、一致性、隔离性、持久性) 事物的隔离级别(读未提交、读以提交、可重复读、可序列化读) 脏读、幻读、不可重复读 数据库的几大范式 数据库常见的命令 说说分库与分表设计 分库与分表带来的分布式困境与应对之策(如何解决分布式下的分库分表,全局表?) 说说 SQL 优化之道 MySQL遇到的死锁问题、如何排查与解决 存储引擎的 InnoDB与MyISAM区别,优缺点,使用场景 索引类别(B+树索引、全文索引、哈希索引)、索引的原理 什么是自适应哈希索引(AHI) 为什么要用 B+tree作为MySQL索引的数据结构 聚集索引与非聚集索引的区别 遇到过索引失效的情况没,什么时候可能会出现,如何解决 limit 20000 加载很慢怎么解决 如何选择合适的分布式主键方案 选择合适的数据存储方案 常见的几种分布式ID的设计方案 常见的数据库优化方案,在你的项目中数据库如何进行优化的 2.2、Redis Redis 有哪些数据类型,可参考《Redis常见的5种不同的数据类型详解》 Redis 内部结构 Redis 使用场景 Redis 持久化机制,可参考《使用快照和AOF将Redis数据持久化到硬盘中》 Redis 集群方案与实现 Redis 为什么是单线程的? 缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级 使用缓存的合理性问题 Redis常见的回收策略 2.3、消息队列 消息队列的使用场景 消息的重发补偿解决思路 消息的幂等性解决思路 消息的堆积解决思路 自己如何实现消息队列 如何保证消息的有序性 三、开源框架和容器 3.1、SSM/Servlet Servlet的生命周期 转发与重定向的区别 BeanFactory 和 ApplicationContext 有什么区别 Spring Bean 的生命周期 Spring IOC 如何实现 Spring中Bean的作用域,默认的是哪一个 说说 Spring AOP、Spring AOP 实现原理 动态代理(CGLib 与 JDK)、优缺点、性能对比、如何选择 Spring 事务实现方式、事务的传播机制、默认的事务类别 Spring 事务底层原理 Spring事务失效(事务嵌套),JDK动态代理给Spring事务埋下的坑,可参考《JDK动态代理给Spring事务埋下的坑!》 如何自定义注解实现功能 Spring MVC 运行流程 Spring MVC 启动流程 Spring 的单例实现原理 Spring 框架中用到了哪些设计模式 Spring 其他产品(Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等) 有没有用到Spring Boot,Spring Boot的认识、原理 MyBatis的原理 可参考《为什么会有Spring》 可参考《为什么会有Spring AOP》 3.2、Netty 为什么选择 Netty 说说业务中,Netty 的使用场景 原生的 NIO 在 JDK 1.7 版本存在 epoll bug 什么是TCP 粘包/拆包 TCP粘包/拆包的解决办法 Netty 线程模型 说说 Netty 的零拷贝 Netty 内部执行流程 Netty 重连实现 3.3、Tomcat Tomcat的基础架构(Server、Service、Connector、Container) Tomcat如何加载Servlet的 Pipeline-Valve机制 可参考:《四张图带你了解Tomcat系统架构!》 四、分布式 4.1、Nginx 请解释什么是C10K问题或者知道什么是C10K问题吗? Nginx简介,可参考《Nginx简介》 正向代理和反向代理. Nginx几种常见的负载均衡策略 Nginx服务器上的Master和Worker进程分别是什么 使用“反向代理服务器”的优点是什么? 4.2、分布式其他 谈谈业务中使用分布式的场景 Session 分布式方案 Session 分布式处理 分布式锁的应用场景、分布式锁的产生原因、基本概念 分布是锁的常见解决方案 分布式事务的常见解决方案 集群与负载均衡的算法与实现 说说分库与分表设计,可参考《数据库分库分表策略的具体实现方案》 分库与分表带来的分布式困境与应对之策 4.3、Dubbo 什么是Dubbo,可参考《Dubbo入门》 什么是RPC、如何实现RPC、RPC 的实现原理,可参考《基于HTTP的RPC实现》 Dubbo中的SPI是什么概念 Dubbo的基本原理、执行流程 五、微服务 5.1、微服务 前后端分离是如何做的? 微服务哪些框架 Spring Could的常见组件有哪些?可参考《Spring Cloud概述》 领域驱动有了解吗?什么是领域驱动模型?充血模型、贫血模型 JWT有了解吗,什么是JWT,可参考《前后端分离利器之JWT》 你怎么理解 RESTful 说说如何设计一个良好的 API 如何理解 RESTful API 的幂等性 如何保证接口的幂等性 说说 CAP 定理、BASE 理论 怎么考虑数据一致性问题 说说最终一致性的实现方案 微服务的优缺点,可参考《微服务批判》 微服务与 SOA 的区别 如何拆分服务、水平分割、垂直分割 如何应对微服务的链式调用异常 如何快速追踪与定位问题 如何保证微服务的安全、认证 5.2、安全问题 如何防范常见的Web攻击、如何方式SQL注入 服务端通信安全攻防 HTTPS原理剖析、降级攻击、HTTP与HTTPS的对比 5.3、性能优化 性能指标有哪些 如何发现性能瓶颈 性能调优的常见手段 说说你在项目中如何进行性能调优 六、其他 6.1、设计能力 说说你在项目中使用过的UML图 你如何考虑组件化、服务化、系统拆分 秒杀场景如何设计 可参考:《秒杀系统的技术挑战、应对策略以及架构设计总结一二!》 6.2、业务工程 说说你的开发流程、如何进行自动化部署的 你和团队是如何沟通的 你如何进行代码评审 说说你对技术与业务的理解 说说你在项目中遇到感觉最难Bug,是如何解决的 介绍一下工作中的一个你认为最有价值的项目,以及在这个过程中的角色、解决的问题、你觉得你们项目还有哪些不足的地方 6.3、软实力 说说你的优缺点、亮点 说说你最近在看什么书、什么博客、在研究什么新技术、再看那些开源项目的源代码 说说你觉得最有意义的技术书籍 工作之余做什么事情、平时是如何学习的,怎样提升自己的能力 说说个人发展方向方面的思考 说说你认为的服务端开发工程师应该具备哪些能力 说说你认为的架构师是什么样的,架构师主要做什么 如何看待加班的问题
徐刘根 2020-03-31 11:22:08 0 浏览量 回答数 0

回答

" 用了两年的时间,终于把这个问题解决了。。######能分享下如何解决的吗###### 分布式事务的基本理论,2PC, QUORUM, PAXOS,系统要达到100w/s的水准靠水平分割 ######好问题,。。。######mark######你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 ###### 两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 ######因为他的说法中有错别字,我没有看到2pc,这一点他的强一致模型确实和最终一致模型概念不清。楼主本身估计不是做架构的,是根据自己公司原来的架构体系自己总结的一些东西。不过楼主的解决方案的大体方向是可行的。###### 引用来自“jobet”的评论你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈######其实这个问题基本上没有正确的方案,每一个平台根据业务性质都会不同,唯一能够提供的就是一个大体的思虑,其他的根据自己的业务性质自行提炼和优化。###### 引用来自“兮风古道”的评论 两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 二段提交的时候,最后一次commit还是会出错的。。######回复 @jobet : 收到。。我搞错了。。######回复 @Brin想写程序 : 2pc是针对于多数据源的事务处理,也就是分布式事务。你说的这个不是。######回复 @jobet : 问一下mysql的autocommit=false后的,commit和rollback难道不是二段提交的吗?这个应该就是数据库的二段提交吧?######2pc的话,对性能的消耗是很大的。估计面试官是因为听到他说2pc就直接否决了,后续的已经没有兴趣了。###### Brin有什么好办法了,记得 博客里补上######我的解决方案是根据用户顺序处理,也就是用顺序一致性替代绝对一致性,然后用分布式消息队列,用一致性哈希算法,只将一个用户的数据发送给同一个处理者,然后按顺序执行这一个人的操作。所以这个是无锁的,可并行的。###### 引用来自“jobet”的评论你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 引用来自“中山野鬼”的评论什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈 我也觉得是具体业务具体分析,比如在电商平台里面,在怎么分布式,买东西这个过程是一个用户触发的。 所以按照用户对纬度,对资源进行水平分割,应该可以解决大部分问题。 但是但是,最麻烦的是先有很多电商平台非常庞大,而且一开始就没有做这种分割,业务是一团乱麻,没人清楚这个用户的购买行为会影响多少台服务器里面的数据,所以只能寻找比较通用的解决方案。 也就是在某个层面上能彻底解决,现在好像思路还是从rpc层面去解决这个问题。找到统一的一劳永逸的中间价或者说体系结构。。 所以我也很难想明白。。######马克,学习了"
kun坤 2020-05-26 13:15:05 0 浏览量 回答数 0

回答

学习另外一门语言主要不是用来提升你的PHP能力的,选语言主要是为了解决不同场景与类型的问题,这也就是为什么会有这么多语言的原因,现在针对你的技能点,我谈下我的想法:第一:PHP框架源码以及设计模式,你阅读各个框架的源码,那么首先你要明确,你是否真正理解其设计思想,与设计理念,你从中吸取了多少作者的思想?如果让你自己写一套框架,你可以真正上手了吗?不要认为,阅读了源码,看的懂代码,就以为明白了,这只是阅读的第一步;第二:nosql,暂且说你都用过这些技术,那么你能很明确的清楚他们之间的最本质的区别吗?技术选型的时候,你能很明确的说出为什么要选这个,这个比起其他几个nosql来说,优势在哪里?再换个方向,你学过了memcache,那么分布式呢?分布式的情况下,memcache如果扩容呢?如何保证其伸缩性,和扩展性呢?第三:环境搭建,优化,负载,mysql主从,那我且问你,你掌握了这些技能,都只是会用,根本谈不上根据场景的变化,做出相应的配置,比如给你1000万-1亿的PV网站,你来架构,你难道还是就一个主从套上去就好了吗?海量数据你又采用什么方式解决呢?最后总结:非常理解楼主认为自己到达瓶颈的想法,上述写的只是想说,不管学习认识的技术,想想这个东西为什么要出来,他的诞生是用来解决什么问题的,最后再研究下他的原理,而不是很多技术,我学过用过就好了,这样没有深入的理解,是不会有多大效果的,最后建议楼主学习一下C语言,可以研究PHP源码,这样在写代码的时候也会考虑性能问题,同时通过C语言的学习,可以研究各种软件的源码和他们的原理,比如memcache,apache,nginx都可以去往源码方面研究,你会看到更多东西,学习JAVA会对你的框架设计思想以及设计模式方面有所提升
我的中国 2019-12-02 00:31:20 0 浏览量 回答数 0

回答

成为一名合格的开发工程师不是一件简单的事情,需要掌握从开发到调试到优化等一系列能力,这些能力中的每一项掌握起来都需要足够的努力和经验。而要成为一名合格的机器学习算法工程师(以下简称算法工程师)更是难上加难,因为在掌握工程师的通用技能以外,还需要掌握一张不算小的机器学习算法知识网络。 下面我们就将成为一名合格的算法工程师所需的技能进行拆分,一起来看一下究竟需要掌握哪些技能才能算是一名合格的算法工程师。 1.基础开发能力 所谓算法工程师,首先需要是一名工程师,那么就要掌握所有开发工程师都需要掌握的一些能力。 有些同学对于这一点存在一些误解,认为所谓算法工程师就只需要思考和设计算法,不用在乎这些算法如何实现,而且会有人帮你来实现你想出来的算法方案。这种思想是错误的,在大多数企业的大多数职位中,算法工程师需要负责从算法设计到算法实现再到算法上线这一个全流程的工作。 笔者曾经见过一些企业实行过算法设计与算法实现相分离的组织架构,但是在这种架构下,说不清楚谁该为算法效果负责,算法设计者和算法开发者都有一肚子的苦水,具体原因不在本文的讨论范畴中,但希望大家记住的是,基础的开发技能是所有算法工程师都需要掌握的。 2.概率和统计基础 概率和统计可以说是机器学习领域的基石之一,从某个角度来看,机器学习可以看做是建立在概率思维之上的一种对不确定世界的系统性思考和认知方式。学会用概率的视角看待问题,用概率的语言描述问题,是深入理解和熟练运用机器学习技术的最重要基础之一。 概率论内容很多,但都是以具体的一个个分布为具体表现载体体现出来的,所以学好常用的概率分布及其各种性质对于学好概率非常重要。 对于离散数据,伯努利分布、二项分布、多项分布、Beta分布、狄里克莱分布以及泊松分布都是需要理解掌握的内容; 对于离线数据,高斯分布和指数分布族是比较重要的分布。这些分布贯穿着机器学习的各种模型之中,也存在于互联网和真实世界的各种数据之中,理解了数据的分布,才能知道该对它们做什么样的处理。 此外,假设检验的相关理论也需要掌握。在这个所谓的大数据时代,最能骗人的大概就是数据了,掌握了假设检验和置信区间等相关理论,才能具备分辨数据结论真伪的能力。例如两组数据是否真的存在差异,上线一个策略之后指标是否真的有提升等等。这种问题在实际工作中非常常见,不掌握相关能力的话相当于就是大数据时代的睁眼瞎。 在统计方面,一些常用的参数估计方法也需要掌握,典型的如最大似然估计、最大后验估计、EM算法等。这些理论和最优化理论一样,都是可以应用于所有模型的理论,是基础中的基础。 3.机器学习理论 虽然现在开箱即用的开源工具包越来越多,但并不意味着算法工程师就可以忽略机器学习基础理论的学习和掌握。这样做主要有两方面的意义: 掌握理论才能对各种工具、技巧灵活应用,而不是只会照搬套用。只有在这个基础上才能够真正具备搭建一套机器学习系统的能力,并对其进行持续优化。否则只能算是机器学习搬砖工人,算不得合格的工程师。出了问题也不会解决,更谈不上对系统做优化。 学习机器学习的基础理论的目的不仅仅是学会如何构建机器学习系统,更重要的是,这些基础理论里面体现的是一套思想和思维模式,其内涵包括概率性思维、矩阵化思维、最优化思维等多个子领域,这一套思维模式对于在当今这个大数据时代做数据的处理、分析和建模是非常有帮助的。如果你脑子里没有这套思维,面对大数据环境还在用老一套非概率的、标量式的思维去思考问题,那么思考的效率和深度都会非常受限。 机器学习的理论内涵和外延非常之广,绝非一篇文章可以穷尽,所以在这里我列举了一些比较核心,同时对于实际工作比较有帮助的内容进行介绍,大家可在掌握了这些基础内容之后,再不断探索学习。 4.开发语言和开发工具 掌握了足够的理论知识,还需要足够的工具来将这些理论落地,这部分我们介绍一些常用的语言和工具。 5.架构设计 最后我们花一些篇幅来谈一下机器学习系统的架构设计。 所谓机器学习系统的架构,指的是一套能够支持机器学习训练、预测、服务稳定高效运行的整体系统以及他们之间的关系。 在业务规模和复杂度发展到一定程度的时候,机器学习一定会走向系统化、平台化这个方向。这个时候就需要根据业务特点以及机器学习本身的特点来设计一套整体架构,这里面包括上游数据仓库和数据流的架构设计,以及模型训练的架构,还有线上服务的架构等等。这一套架构的学习就不像前面的内容那么简单了,没有太多现成教材可以学习,更多的是在大量实践的基础上进行抽象总结,对当前系统不断进行演化和改进。但这无疑是算法工程师职业道路上最值得为之奋斗的工作。在这里能给的建议就是多实践,多总结,多抽象,多迭代。 6.机器学习算法工程师领域现状 现在可以说是机器学习算法工程师最好的时代,各行各业对这类人才的需求都非常旺盛。典型的包括以下一些细分行业: 推荐系统。推荐系统解决的是海量数据场景下信息高效匹配分发的问题,在这个过程中,无论是候选集召回,还是结果排序,以及用户画像等等方面,机器学习都起着重要的作用。 广告系统。广告系统和推荐系统有很多类似的地方,但也有着很显著的差异,需要在考虑平台和用户之外同时考虑广告主的利益,两方变成了三方,使得一些问题变复杂了很多。它在对机器学习的利用方面也和推荐类似。 搜索系统。搜索系统的很多基础建设和上层排序方面都大量使用了机器学习技术,而且在很多网站和App中,搜索都是非常重要的流量入口,机器学习对搜索系统的优化会直接影响到整个网站的效率。 风控系统。风控,尤其是互联网金融风控是近年来兴起的机器学习的又一重要战场。不夸张地说,运用机器学习的能力可以很大程度上决定一家互联网金融企业的风控能力,而风控能力本身又是这些企业业务保障的核心竞争力,这其中的关系大家可以感受一下。 但是所谓“工资越高,责任越大”,企业对于算法工程师的要求也在逐渐提高。整体来说,一名高级别的算法工程师应该能够处理“数据获取数据分析模型训练调优模型上线”这一完整流程,并对流程中的各种环节做不断优化。一名工程师入门时可能会从上面流程中的某一个环节做起,不断扩大自己的能力范围。 除了上面列出的领域以外,还有很多传统行业也在不断挖掘机器学习解决传统问题的能力,行业的未来可谓潜力巨大。
寒凝雪 2019-12-02 01:21:12 0 浏览量 回答数 0

问题

如何基于 dubbo 进行服务治理、服务降级、失败重试以及超时重试?【Java问答学堂】51期

面试题 如何基于 dubbo 进行服务治理、服务降级、失败重试以及超时重试? 面试官心理分析 服务治理,这个问题如果问你,其实就是看看你有没有服务治理的思想,因为这个是做过复杂微...
剑曼红尘 2020-07-06 11:19:50 0 浏览量 回答数 0

回答

大数据就是多,就是多。原来的设备存不下、算不动。 ——啪菠萝·毕加索 大数据,不是随机样本,而是所有数据;不是精确性,而是混杂性;不是因果关系,而是相关关系。—— Schönberger 顾名思义“大数据”,从字面意思来理解就是“大量的数据”。 从技术的的角度来解释,大数据就是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。 IBM提出大数据具有5V特点:Volume(大量)、Velocity(高速)、Variety(多样)、Value(低价值密度)、Veracity(真实性)。 我们所谈论的大数据实际上更多是从应用的层面,比如某公司搜集、整理了大量的用户行为信息,然后通过数据分析手段对这些信息进行分析从而得出对公司有利用价值的结果。 比如:头条的推荐机制,就是建立在对海量用户的阅读信息的搜集、分析之上。这就是大数据在现实中具体体现。 那Hadoop又是什么?它和大数据又有什么联系呢? Hadoop是一个对海量数据进行处理的分布式系统架构,可以理解为Hadoop就是一个对大量的数据进行分析的工具,和其他组件搭配使用,来完成对大量数据的收集、存储和计算。 Hadoop框架最核心的设计就是:HDFS 和 MapReduce。 HDFS为海量的数据提供了存储;MapReduce为海量的数据提供了计算。 一套完整的Hadoop大数据生态系统基本包含这些组件。 HDFS:Hadoop分布式文件系统,专门存储超大数据文件,为整个Hadoop生态圈提供了基础的存储服务。 MapReduce:分布式离线计算框架,用来处理大量的已经存储在本地的离线数据。 Storm:分布式实时计算,主要特点是实时性,用来处理实时产生的数据。 ZooKeeper:用于Hadoop的分布式协调服务。Hadoop的许多组件依赖于Zookeeper,它运行在计算机集群上面,用于管理Hadoop操作。 HBase:是一个建立在HDFS之上,面向列的NoSQL数据库,用于快速读/写大量数据。 Hive:基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表。 Sqoop:是一个连接工具,用于在关系数据库、数据仓库和Hadoop之间转移数据。 Pig:它是MapReduce编程的复杂性的抽象。Pig平台包括运行环境和用于分析Hadoop数据集的脚本语言(Pig Latin)。
1748847708358317 2019-12-02 03:11:07 0 浏览量 回答数 0

问题

荆门开诊断证明-scc

(微)电〗【186-6605-3854〗号【精品问答】Java技术1000问(1) 问问小秘 2019-11-15 11:24:15 9099 为了方便Java开发者快速找到相关技术问题和答案,开发...
游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

回答

Java架构师,首先要是一个高级java攻城狮,熟练使用各种框架,并知道它们实现的原理。jvm虚拟机原理、调优,懂得jvm能让你写出性能更好的代码;池技术,什么对象池,连接池,线程池……    Java反射技术,写框架必备的技术,但是有严重的性能问题,替代方案java字节码技术;nio,没什么好说的,值得注意的是”直接内存”的特点,使用场景;java多线程同步异步;java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效的解决问题,比如hashmap的实现原理,好多五年以上经验的人都弄不清楚,还有为什扩容时有性能问题?不弄清楚这些原理,就写不出高效的代码,还会认为自己做的很对;总之一句话越基础的东西越重要,很多人认为自己会用它们写代码了,其实仅仅是知道如何调用api而已,离会用还差的远。    熟练使用各种数据结构和算法,数组、哈希、链表、排序树…,一句话要么是时间换空间要么是空间换时间,这里展开可以说一大堆,需要有一定的应用经验,用于解决各种性能或业务上的问题。    熟练使用linux操作系统,必备,没什么好说的 。    熟悉tcp协议,创建连接三次握手和断开连接四次握手的整个过程,不了解的话,无法对高并发网络应用做优化; 熟悉http协议,尤其是http头,我发现好多工作五年以上的都弄不清session和cookie的生命周期以及它们之间的关联。    系统集群、负载均衡、反向代理、动静分离,网站静态化 。    分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点,适用场景 。    分布式缓存技术memcached,redis,提高系统性能必备,一句话,把硬盘上的内容放到内存里来提速,顺便提个算法一致性hash 。    工具nginx必备技能超级好用,高性能,基本不会挂掉的服务器,功能多多,解决各种问题。    数据库的设计能力,mysql必备,最基础的数据库工具,免费好用,对它基本的参数优化,慢查询日志分析,主从复制的配置,至少要成为半个mysql dba。其他nosql数据库如mongodb。    还有队列中间件。如消息推送,可以先把消息写入数据库,推送放队列服务器上,由推送服务器去队列获取处理,这样就可以将消息放数据库和队列里后直接给用户反馈,推送过程则由推送服务器和队列服务器完成,好处异步处理、缓解服务器压力,解藕系统。   以上纯粹是常用的技术,还有很多自己慢慢去摸索吧;因为要知道的东西很多,所以要成为一名合格的架构师,必须要有强大的自学能力,没有人会手把手的教给你所有的东西。    想成为架构师不是懂了一大堆技术就可以了,这些是解决问题的基础、是工具,不懂这些怎么去提解决方案呢?这是成为架构师的必要条件。    架构师要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格,人家一个几百人用户的系统,访问量不大,数据量小,你给人家上集群、上分布式存储、上高端服务器,为了架构而架构,这是最扯淡的,架构师的作用就是第一满足业务需求,第二最低的硬件网络成本和技术维护成本。    架构师还要根据业务发展阶段,提前预见发展到下一个阶段系统架构的解决方案,并且设计当前架构时将架构的升级扩展考虑进去,做到易于升级;否则等系统瓶颈来了,出问题了再去出方案,或现有架构无法扩展直接扔掉重做,或扩展麻烦问题一大堆,这会对企业造成损失。Java架构师学习路线图如:https://yq.aliyun.com/articles/225941?spm=5176.8091938.0.0.qyp0tC
zwt9000 2019-12-02 00:25:32 0 浏览量 回答数 0

问题

为什么要进行系统拆分?如何进行系统拆分?拆分后不用 dubbo 可以吗?【Java问答学堂】46期

面试题 为什么要进行系统拆分?如何进行系统拆分?拆分后不用 dubbo 可以吗? 面试官心理分析 从这个问题开始就进行分布式系统环节了,现在出去面试分布式都成标配了,...
剑曼红尘 2020-06-29 16:39:00 6 浏览量 回答数 1

问题

【精品问答】大数据常见问题之flink五十问第二期

Flink五十问 第二期分为基础篇与进阶篇 持续关注有惊喜~ 基础篇 1.简单介绍一下Flink 2.Flink相比Spark Streaming有什么区别? 3.Flink的组件栈是怎么样的 4.Flink的基础编程模型了...
茶什i 2019-12-01 22:02:36 263 浏览量 回答数 0

回答

看数据量咯,也就是那200ms的价值,在可观的未来,如果数据量会暴涨,上方案2######在大家心里可以承受的时间范围内就方案2。 假如批量数据处理方案2需要1个小时,这时候方案1的重要性来了,毕竟时间减少了一半。######数据量增多到预想的情况下,你跑一下看看能否接受这种效率,能的话方案2。。当然从性能来讲当然选方案1了######确认算法保证没错的情况用1######刨除数据量、硬件成本、时间成本,没法判断的。 真实处理的数据量是多少,能否通过分布式提高效率,可以接受的最长业务处理时间是多少?离开这些谈算法,都是没意义的。 实际上,现代的计算时间早就是大白菜了,所以99.99%的时候,算法2都比1要合适。虽然慢一倍,但是算法的排错修改时间肯定远远小于1,至于慢的速度,拿十倍20倍的硬件堆就是。###### 引用来自“魔力猫”的评论 刨除数据量、硬件成本、时间成本,没法判断的。 真实处理的数据量是多少,能否通过分布式提高效率,可以接受的最长业务处理时间是多少?离开这些谈算法,都是没意义的。 实际上,现代的计算时间早就是大白菜了,所以99.99%的时候,算法2都比1要合适。虽然慢一倍,但是算法的排错修改时间肯定远远小于1,至于慢的速度,拿十倍20倍的硬件堆就是。 用硬件对不妨是一个解决办法,但还是要结合实际的业务场景来决定的 关键还是要看你这个计算再在你整个要解决的业务场景中所占的比重,比重越高性能要求越高######再写一层封装,自动选择算法不就行了吗。 比如说什么情况下用算法1,什么情况下用算法2。这样还有个扩展性的好处,以后你又发现了新算法。你还可以加在里面,什么时候用算法3都是没有问题的。######一个运算就消耗200ms,A星寻路算法(图形寻路比较高效且适用性比较广以及相对复杂的逻辑算法,在此随便举例而已),如果是这个时间级别都得使劲优化。400ms的方案二直接pass掉,哪怕方案一只耗时200ms,你测试一下并发量看看,耗时100ms的业务并发就很糟糕了(单机情况),自己实测一下你就知道200ms的差距是什么概念了。 如果并发情况加锁同步执行一个200ms耗时的算法,加锁同步也就可以理解为顺序执行,你想想1s也就执行5次而已,那些说堆硬件的简直胡扯,堆硬件只是没办法的办法。哪怕是方案一,我觉得如果还有优化的空间还得优化。 如果软件没有并发需求,即不会有多用户同时触发执行此算法的情况下,方案二当然是可以的。######有条件的情况,当然是越快的算法越好,根据数据量取优的话,需要大量测试,根据曲线取临界值的
kun坤 2020-05-30 22:45:53 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。
hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

关于并行计算的一些基础开放问题

题目: 关于并行计算的一些基础开放问题。 出题人:阿里巴巴出题专家:何万青/阿里云高性能计算资深技术专家 ◼ 如何定义并计算,请分别阐述分布式内存到共享内存模式行编程...
Runt 2020-04-14 18:20:04 0 浏览量 回答数 1

问题

【百问百答】Apache Spark 中文实战攻略

1、Apache Spark 3.0 是什么? 2、Apache Spark 3.0 与性能相关的新功能主要有哪些? 3、 Spark 3.0 的Adaptive Query Execution是什么࿱...
爱吃鱼的程序员 2020-12-28 14:33:41 25 浏览量 回答数 0

回答

Re阿里云运行Windows本地程序的问题 楼主这种计算使用云服务器的会比较贵。云服务器的运算能力比直接购买最新的较高配置家用电脑要贵,你不应该依靠硬件,就算是要优化,也要先优化软件。 不论你用什么机器,最关键的是你的软件的算法必须支持多CPU,要知道我们的程序都有支持CPU的上限,比如说音乐播放器这种也就是单核运算,就算你装个100个4核CPU,这个软件也只是使用一个cpu的1个核心。像星际争霸这个游戏用的是双核心,你就是装在多核心CPU,他也只跑满2个核心,他的性能取决于这两个核心最高速度,所以说我们玩星际的时候一些高频率的双核比低频率的4核更快。 再说你的这个软件,是否支持多核心呢,如果支持多核心是支持多少核心,不要以为安装了16个核心的机器,16个核心就全能用起来,根据这个核心数去组装你的pc机才是最大程度的性价比?对于复杂计算,我们应该改进软件采取分布式计算,比如我们得到一个需要计算的大数据,最常用是多台机器并行计算,我们应该先进性简单的数据计算任务分割,将不同的任务分割到不同的机器去,然后再将最后的计算结果进行合并,效率就能提升。
ayouny 2019-12-02 01:57:40 0 浏览量 回答数 0

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

演讲人:章文嵩博士,阿里集团的高级研究员与副总裁,主要负责基础核心软件研发和云计算产品研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本电子商务基础设施。他也是开放源码及 Linux内...
云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。
封神 2019-12-02 02:00:50 0 浏览量 回答数 0

问题

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

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

问题

基于Java容器的多应用部署技术实践【精品问答集锦】

本期请来了阿里中间件技术专家魏鹏 (豫楚)直播分享基于Java容器的多应用部署技术实践直播简介随着业务的发展,机器的数量和系统复杂性不断提升,较之简单系统的开发部署,大规模分布式系统将会面对以下新问题:性能问题,系统之间通过远程调用来进行数...
管理贝贝 2019-12-01 20:28:27 52422 浏览量 回答数 55

问题

如何构建机器学习算法?

前言 本系列文章为《Deep Learning》读书笔记,可以参看原书一起阅读,效果更佳。我们前面也介绍了一些构建机器学习或深度学习的一些内容,理解了其中部分原理和这么做的原因,接下...
问问小秘 2020-04-15 14:07:23 0 浏览量 回答数 1

回答

strong consistency across distributed node not supported 不支持全局强一致 报错信息:strong consistency across distributed node not supported OB版本:  1.x 报错原因: OceanBase 1.x 版本不支全局一致性查询。在1.x版本里,当SQL要查询的数据分布在不同OBServer节点上时,由于没有内置全局时钟,所以无法获取不同OBServer节点上同一个时刻的数据。 解决办法: 1. 在1.x版本里。如果SQL访问的是多个表,且表之间有业务联系,则将多个表设置为相同的表分组(tablegroup)可以规避这个问题;如果SQL访问的是单个分区表,且能接受延时,可以使用弱一致读hint来规避报错;否则,暂时无解。  弱一致读hint详情请参考官方文档 弱一致读(ob_read_consistency) 2. 计划在2.1版本里,支持全局一致性查询,就没有这个问题。 ------------------------- ERROR 4624 (HY000): machine resource is not enough to hold a new unit 报错信息:ERROR 4624 (HY000): machine resource is not enough to hold a new unit OB版本:所有版本 报错原因:     OceanBase从某个角度来说就是将一批机器的资源(CPU/Memory/Disk)聚合在一起形成一个大的“资源池”,然后再从里面分配资源。每个租户都得绑定至少一个Resource Pool。Resource Pool就是从原始的“资源池”里创建出来的。每个Resource Pool由N个相同的Unit组成。每个Unit在某个具体的OBServer内部分配。当创建新的Resource Pool或者调大老的Resource Pool规格时,可能会因为没有OBServer可以分配出对应规格的Unit而报错。 解决办法:     重新计算可用资源,调制分配资源的SQL里的规格。如果可用资源确实不够用,那就先补充机器资源或者释放不用的租户资源,然后再重试。 ------------------------- OceanBase是否开源? 汇总一下有关OceanBase和开源相关的问题的答案。 1. OceanBase 0.4曾经开源,地址为 alibaba/oceanbase 。 喜欢看代码的从中可以学习到一些分布式数据库开发经验。 2. OceanBase从1.0版本不再开源,架构上做了很大的重构,对SQL和存储功能都有加强。不过关于LSM结构、冻结合并的原理没有大变。当前版本进入2.0。将来是否开源目前并无信息。 3. OceanBase 在用户体验上像MySQL,但是绝不是MySQL,也不是基于MySQL版本修改的,不是基于Postgre修改的,不是基于其他任何开源的产品修改的。OceanBase是蚂蚁自主研发的纯粹的分布式数据库,产品开发过程中,特别注意避免侵犯其他公司专利。所以OceanBase是按照一个商业通用数据库去规划设计的。 4. 随时欢迎开发能力很强的同学加入OceanBase内核开发团队。 ------------------------- OceanBase支持分布式事务吗? OceanBase提供多租户能力(租户就是实例)。租户内的分布式事务需求,OceanBase是满足的。原理是两阶段提交协议,强一致。OceanBase对分布式事务两阶段提交过程做了一些优化,性能有提升。如果业务的事务范围超出了租户(实例)的边界,则必须借助第三方分布式事务中间件框架或者应用自己实现分布式事务。蚂蚁SOFA的分布式事务框架DTX支持三种分布式事务方法,即XA、TCC和FMT.其中TCC和FMT都是最终一致。 ------------------------- Q: OceanBase里创建索引是立即生效吗?唯一索引呢?A: 分场景。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x 版本的索引 ------------------------- OceanBase合并触发条件 Q:OceanBase什么时候会触发「合并」? A: OceanBase的数据写之前事务日志redo会及时落盘,但是数据的增量修改会一直在OB的增量内存memtable里,每天会落盘一次,这个就是合并。合并时间可以设定(major_freeze_duty_time)。另外,如果memtable使用率超过阈值(freeze_trigger_percentage),就会触发「冻结」,然后就是minor compaction,以及「转储」操作。转储会释放memtable内存,增量数据被输出到磁盘上,转储有次数限制(最大由参数minor_freeze_times),这个次数用完了就会触发「合并」。合并会比较耗OB的资源,时间长短取决于有多少增量数据要跟基线数据合并。 ## 查看冻结转储参数SHOW parameters WHERE NAME IN ('enable_major_freeze','minor_freeze_times','freeze_trigger_percentage','major_freeze_duty_time') AND svr_ip IN ('11.166.175.6');## 触发冻结合并ALTER system major freeze;SELECT sleep(1);## 查看冻结合并历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, module, EVENT,name1,value1,name2,value2 FROM __all_rootservice_event_history hWHERE h.module IN ('daily_merge','major_freeze', 'root_service')ORDER BY gmt_create DESC LIMIT 50; 示例:
mq4096 2019-12-02 00:39:59 0 浏览量 回答数 0

回答

strong consistency across distributed node not supported 不支持全局强一致 报错信息:strong consistency across distributed node not supported OB版本:  1.x 报错原因: OceanBase 1.x 版本不支全局一致性查询。在1.x版本里,当SQL要查询的数据分布在不同OBServer节点上时,由于没有内置全局时钟,所以无法获取不同OBServer节点上同一个时刻的数据。 解决办法: 1. 在1.x版本里。如果SQL访问的是多个表,且表之间有业务联系,则将多个表设置为相同的表分组(tablegroup)可以规避这个问题;如果SQL访问的是单个分区表,且能接受延时,可以使用弱一致读hint来规避报错;否则,暂时无解。  弱一致读hint详情请参考官方文档 弱一致读(ob_read_consistency) 2. 计划在2.1版本里,支持全局一致性查询,就没有这个问题。 ------------------------- ERROR 4624 (HY000): machine resource is not enough to hold a new unit 报错信息:ERROR 4624 (HY000): machine resource is not enough to hold a new unit OB版本:所有版本 报错原因:     OceanBase从某个角度来说就是将一批机器的资源(CPU/Memory/Disk)聚合在一起形成一个大的“资源池”,然后再从里面分配资源。每个租户都得绑定至少一个Resource Pool。Resource Pool就是从原始的“资源池”里创建出来的。每个Resource Pool由N个相同的Unit组成。每个Unit在某个具体的OBServer内部分配。当创建新的Resource Pool或者调大老的Resource Pool规格时,可能会因为没有OBServer可以分配出对应规格的Unit而报错。 解决办法:     重新计算可用资源,调制分配资源的SQL里的规格。如果可用资源确实不够用,那就先补充机器资源或者释放不用的租户资源,然后再重试。 ------------------------- OceanBase是否开源? 汇总一下有关OceanBase和开源相关的问题的答案。 1. OceanBase 0.4曾经开源,地址为 alibaba/oceanbase 。 喜欢看代码的从中可以学习到一些分布式数据库开发经验。 2. OceanBase从1.0版本不再开源,架构上做了很大的重构,对SQL和存储功能都有加强。不过关于LSM结构、冻结合并的原理没有大变。当前版本进入2.0。将来是否开源目前并无信息。 3. OceanBase 在用户体验上像MySQL,但是绝不是MySQL,也不是基于MySQL版本修改的,不是基于Postgre修改的,不是基于其他任何开源的产品修改的。OceanBase是蚂蚁自主研发的纯粹的分布式数据库,产品开发过程中,特别注意避免侵犯其他公司专利。所以OceanBase是按照一个商业通用数据库去规划设计的。 4. 随时欢迎开发能力很强的同学加入OceanBase内核开发团队。 ------------------------- OceanBase支持分布式事务吗? OceanBase提供多租户能力(租户就是实例)。租户内的分布式事务需求,OceanBase是满足的。原理是两阶段提交协议,强一致。OceanBase对分布式事务两阶段提交过程做了一些优化,性能有提升。如果业务的事务范围超出了租户(实例)的边界,则必须借助第三方分布式事务中间件框架或者应用自己实现分布式事务。蚂蚁SOFA的分布式事务框架DTX支持三种分布式事务方法,即XA、TCC和FMT.其中TCC和FMT都是最终一致。 ------------------------- Q: OceanBase里创建索引是立即生效吗?唯一索引呢?A: 分场景。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x 版本的索引 ------------------------- OceanBase合并触发条件 Q:OceanBase什么时候会触发「合并」? A: OceanBase的数据写之前事务日志redo会及时落盘,但是数据的增量修改会一直在OB的增量内存memtable里,每天会落盘一次,这个就是合并。合并时间可以设定(major_freeze_duty_time)。另外,如果memtable使用率超过阈值(freeze_trigger_percentage),就会触发「冻结」,然后就是minor compaction,以及「转储」操作。转储会释放memtable内存,增量数据被输出到磁盘上,转储有次数限制(最大由参数minor_freeze_times),这个次数用完了就会触发「合并」。合并会比较耗OB的资源,时间长短取决于有多少增量数据要跟基线数据合并。 ## 查看冻结转储参数SHOW parameters WHERE NAME IN ('enable_major_freeze','minor_freeze_times','freeze_trigger_percentage','major_freeze_duty_time') AND svr_ip IN ('11.166.175.6');## 触发冻结合并ALTER system major freeze;SELECT sleep(1);## 查看冻结合并历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, module, EVENT,name1,value1,name2,value2 FROM __all_rootservice_event_history hWHERE h.module IN ('daily_merge','major_freeze', 'root_service')ORDER BY gmt_create DESC LIMIT 50; 示例:
mq4096 2019-12-02 00:40:00 0 浏览量 回答数 0

问题

【精品问答】python必备面试干货

谁能想到60%开发者想要学习的python,竟然诞生于80年代的圣诞节期间。 在阿姆斯特丹,百无聊赖的Guido决心开发继承ABC语言的脚本解释程序。就这样,python在Guido的手中诞生了。...
问问小秘 2019-12-01 21:53:38 1125 浏览量 回答数 2

回答

基础:比如计算机系统、算法、编译原理等等 Web开发: 主要是Web开发相关的内容,包括HTML/CSS/JS(前端页面)、Servlet/JSP(J2EE)以及Mysql(数据库)相关的知识。它们的学习顺序应该是从前到后,因此最先学习的应该是HTML/CSS/JS(前端页面),这部分内容你可以去上面的那个runoob网站上找。J2EE:你需要学习的是Servlet/JSP(J2EE)部分,这部分是Java后端开发必须非常精通的部分,因此这部分是这三部分中最需要花精力的。关于Servlet/Jsp部分视频的选择,业界比较认可马士兵的视频 。最后一步,你需要学会使用数据库,mysql是个不错的入门选择,而且Java领域里主流的关系型数据库就是mysql。这部分一般在你学习Servlet/Jsp的时候,就会接触到的,其中的JDBC部分就是数据库相关的部分。你不仅要学会使用JDBC操作数据库,还要学会使用数据库客户端工具,比如navicat,sqlyog,二选一即可。开发框架:目前比较主流的是SSM框架,即spring、springmvc、mybatis。你需要学会这三个框架的搭建,并用它们做出一个简单的增删改查的Web项目。你可以不理解那些配置都是什么含义,以及为什么要这么做,这些留着后面你去了解。但你一定要可以快速的利用它们三个搭建出一个Web框架,你可以记录下你第一次搭建的过程,相信我,你一定会用到的。还要提一句的是,你在搭建SSM的过程中,可能会经常接触到一个叫maven的工具。这个工具也是你以后工作当中几乎是必须要使用的工具,所以你在搭建SSM的过程中,也可以顺便了解一下maven的知识。在你目前这个阶段,你只需要在网络上了解一下maven基本的使用方法即可,一些高端的用法随着你工作经验的增加,会逐渐接触到的。在这一年里,你至少需要看完《Java编程思想》这本书。这本书的内容是帮助你对于Java有一个更加深入的了解,是Java基础的升级版。 总而言之,这个阶段的核心学习思想就是,在工作中实践,并且更加深入的了解Java基础。对于参加工作1年到2年的同学。这部分时间段的同学,已经对Java有了一个更加深入的了解。但是对于面向对象的体会可能还不够深刻,编程的时候还停留在完成功能的层次,很少会去考虑设计的问题。于是这个时候,设计模式就来了。我当时看的是《大话设计模式》这本书,并且写了完整版的设计模式博客。因此,我要求大家,最多在你工作一年的时候,必须开始写博客,而设计模式就是你博客的开端。此外,设计模式并不是你这一年唯一的任务,你还需要看一些关于代码编写优化的书。比如《重构 改善既有代码的设计》,《effective java》。总而言之,这个阶段,你的核心任务就是提高你的代码能力,要能写出一手优雅的代码。对于参加工作2年到3年的同学有的同学在这个时候觉得自己已经很牛逼了,于是忍不住开始慢慢松懈。请记住,你还嫩的多。这个阶段,有一本书是你必须看的,它叫做《深入理解Java虚拟机》。这本书绝对是Java开发者最重要的书,没有之一。在我眼里,这本书的重要性还要高于《Java编程思想》。这本书的内容是帮助你全面的了解Java虚拟机,在这个阶段,你一定已经知道Java是运行在JVM之上的。所以,对于JVM,你没有任何理由不了解它。这个时候,你应该去更加深入的了解并发相关的知识,而这部分内容,我比较推荐《Java并发编程实战》这本书。只要你把这本书啃下来了,并发的部分基本已经了解了十之六七。与此同时,这个阶段你要做的事情还远不止如此。这个时候,你应该对于你所使用的框架应该有了更深入的了解,对于Java的类库也有了更深入的了解。因此,你需要去看一些JDK中的类的源码,也包括你所使用的框架的源码。这些源码能看懂的前提是,你必须对设计模式非常了解。否则的话,你看源码的过程中,永远会有这样那样的疑问,这段代码为什么要这么写?为什么要定义这个接口,它看起来好像很多余?由此也可以看出,这些学习的过程是环环相扣的,如果你任何一个阶段拉下来了,那么你就真的跟不上了,或者说是一步慢步步慢。而且我很负责的告诉你,我在这个阶段的时候,所学习的东西远多于这里所罗列出来的。总而言之,这个阶段,你需要做的是深入了解Java底层和Java类库(比如并发那本书就是Java并发包java.concurrent的内容),也就是JVM和JDK的相关内容。而且还要更深入的去了解你所使用的框架,方式比较推荐看源码或者看官方文档。另外,还有一种学习的方式,在2年这个阶段,也应该启用了,那就是造轮子。不要听信那套“不要重复造轮子”的论调,那是公司为了节省时间成本编造出来的。重复造轮子或许对别人没有价值,因为你造的轮子可能早就有了,而且一般情况下你造出来的轮子还没有现存的好。  但是对别人没有价值,不代表对你自己没有价值。一个造轮子的过程,是一个从无到有的过程。这个过程可以对你进行系统的锻炼,它不仅考察你的编码能力,还考察你的框架设计能力,你需要让你的轮子拥有足够好的扩展性、健壮性。而且在造轮子的过程中,你会遇到各种各样的难题,这些难题往往又是你学习的契机。当你把轮子造好的时候,你一定会发现,其实你自己收获了很多。所以,这个阶段,除了上面提到的了解JVM、JDK和框架源码以外,也请你根据别人优秀的源码,去造一个任何你能够想象出来的轮子。第四部分:参加工作3年到4年的同学这个阶段的同学,提升已经是很难了,而且这个阶段的学习往往会比较多样化。因为在前3年的过程中,你肯定或多或少接触过一些其它的技术,比如大数据、分布式缓存、分布式消息服务、分布式计算、软负载均衡等等。这些技术,你能精通任何一项,都将是你未来面试时巨大的优势,因此如果你对某一项技术感兴趣的话,  这个时候可以深入去研究一下。这项技术不一定是你工作所用到的,但一定是相关的。而且在研究一门新技术时,切忌朝三暮四。有的同学今天去整整大数据,搞搞Hadoop、hbase一类的东西。过不了一段时间,就觉得没意思,又去研究分布式缓存,比如redis。然后又过不了一段时间,又去研究分布式计算,比如整整Mapreduce或者storm。结果到最后,搞得自己好像什么都会一样,在简历上大言不惭的写上大数据、分布式缓存、分布式计算都了解,其实任何一个都只是浮于表面。到时候面试官随便一问,就把你给识破了。我比较推崇的基础书籍有三本,分别是《深入理解计算机系统》,《tcp/ip详解 卷一、二、三》,《数据结构与算法》。其中TCP/IP有三本书,但我们这里把这三本看成是一本大书。这三本分别适合三种人,《深入理解计算机系统》比较适合一直从事Java Web开发和APP后端开发工作的人群。《tcp/ip详解 卷一、二、三》比较适合做网络编程的人群,比如你使用netty去开发的话,那么就要对TCP/IP有更深入的了解。而《数据结构与算法》这本书,则比较适合做计算研究工作的人,比如刚才提到的分布式计算。另外,我要强调的是,这里所说的适合,并不是其它两本对你就没有用。比如你做Java Web和APP后端开发,《tcp/ip详解 卷一、二、三》这本书对你的作用也是很大的。这里只是分出个主次关系而已,你要是时间足够的话,能把三本都精读那当然最好不过了。第五部分:参加工作4年到5年的同学经过前面一年的历练,相信你在自己所钻研的领域已经有了自己一定的见解,这个时候,技术上你应该已经遇到瓶颈了。这个时候不要着急提高自己的技术,已经是时候提高你的影响力了,你可以尝试去一些知名的公司去提高你的背景,你可以发表一些文章去影响更多的人。当然,你也可以去Github创建一个属于你的开源项目,去打造自己的产品。  这次的开源项目不同于之前的造轮子,你这个时候是真的要去尽量尝试造出来真正对别人有价值的轮子。技术学到这个阶段,很容易遇到瓶颈,而且往往达到一定程度后,你再深入下去的收效就真的微乎其微了,除非你是专门搞学术研究的。然而很可惜,大部分程序猿做不到这一步,那是科学家做的事情。这个时候提高影响力不仅仅是因为技术上容易遇到瓶颈,更多的是影响力可以给你创造更多的机会。程序猿在某种程度上和明星很像,一个好的电视剧和电影就可以成就一批明星,程序猿有的时候也是,一个好的项目就可以成就一群程序猿。比如国内几个脍炙人口的项目,像淘宝、支付宝、QQ、百度、微信等等。这每一个项目,都成就了一批程序猿。我敢说,这里面任何一个项目,如果你是它的核心开发,光是这样一个Title,就已经是你非常大的优势。更何况还不止如此,Title说到底也是个名头,更重要的是,这种项目在做的时候,对你的历练一定也是非常给力的。
hiekay 2019-12-02 01:38:44 0 浏览量 回答数 0

回答

基础:比如计算机系统、算法、编译原理等等 Web开发: 主要是Web开发相关的内容,包括HTML/CSS/JS(前端页面)、Servlet/JSP(J2EE)以及Mysql(数据库)相关的知识。它们的学习顺序应该是从前到后,因此最先学习的应该是HTML/CSS/JS(前端页面),这部分内容你可以去上面的那个runoob网站上找。J2EE:你需要学习的是Servlet/JSP(J2EE)部分,这部分是Java后端开发必须非常精通的部分,因此这部分是这三部分中最需要花精力的。关于Servlet/Jsp部分视频的选择,业界比较认可马士兵的视频 。最后一步,你需要学会使用数据库,mysql是个不错的入门选择,而且Java领域里主流的关系型数据库就是mysql。这部分一般在你学习Servlet/Jsp的时候,就会接触到的,其中的JDBC部分就是数据库相关的部分。你不仅要学会使用JDBC操作数据库,还要学会使用数据库客户端工具,比如navicat,sqlyog,二选一即可。开发框架:目前比较主流的是SSM框架,即spring、springmvc、mybatis。你需要学会这三个框架的搭建,并用它们做出一个简单的增删改查的Web项目。你可以不理解那些配置都是什么含义,以及为什么要这么做,这些留着后面你去了解。但你一定要可以快速的利用它们三个搭建出一个Web框架,你可以记录下你第一次搭建的过程,相信我,你一定会用到的。还要提一句的是,你在搭建SSM的过程中,可能会经常接触到一个叫maven的工具。这个工具也是你以后工作当中几乎是必须要使用的工具,所以你在搭建SSM的过程中,也可以顺便了解一下maven的知识。在你目前这个阶段,你只需要在网络上了解一下maven基本的使用方法即可,一些高端的用法随着你工作经验的增加,会逐渐接触到的。在这一年里,你至少需要看完《Java编程思想》这本书。这本书的内容是帮助你对于Java有一个更加深入的了解,是Java基础的升级版。 总而言之,这个阶段的核心学习思想就是,在工作中实践,并且更加深入的了解Java基础。对于参加工作1年到2年的同学。这部分时间段的同学,已经对Java有了一个更加深入的了解。但是对于面向对象的体会可能还不够深刻,编程的时候还停留在完成功能的层次,很少会去考虑设计的问题。于是这个时候,设计模式就来了。我当时看的是《大话设计模式》这本书,并且写了完整版的设计模式博客。因此,我要求大家,最多在你工作一年的时候,必须开始写博客,而设计模式就是你博客的开端。此外,设计模式并不是你这一年唯一的任务,你还需要看一些关于代码编写优化的书。比如《重构 改善既有代码的设计》,《effective java》。总而言之,这个阶段,你的核心任务就是提高你的代码能力,要能写出一手优雅的代码。对于参加工作2年到3年的同学有的同学在这个时候觉得自己已经很牛逼了,于是忍不住开始慢慢松懈。请记住,你还嫩的多。这个阶段,有一本书是你必须看的,它叫做《深入理解Java虚拟机》。这本书绝对是Java开发者最重要的书,没有之一。在我眼里,这本书的重要性还要高于《Java编程思想》。这本书的内容是帮助你全面的了解Java虚拟机,在这个阶段,你一定已经知道Java是运行在JVM之上的。所以,对于JVM,你没有任何理由不了解它。这个时候,你应该去更加深入的了解并发相关的知识,而这部分内容,我比较推荐《Java并发编程实战》这本书。只要你把这本书啃下来了,并发的部分基本已经了解了十之六七。与此同时,这个阶段你要做的事情还远不止如此。这个时候,你应该对于你所使用的框架应该有了更深入的了解,对于Java的类库也有了更深入的了解。因此,你需要去看一些JDK中的类的源码,也包括你所使用的框架的源码。这些源码能看懂的前提是,你必须对设计模式非常了解。否则的话,你看源码的过程中,永远会有这样那样的疑问,这段代码为什么要这么写?为什么要定义这个接口,它看起来好像很多余?由此也可以看出,这些学习的过程是环环相扣的,如果你任何一个阶段拉下来了,那么你就真的跟不上了,或者说是一步慢步步慢。而且我很负责的告诉你,我在这个阶段的时候,所学习的东西远多于这里所罗列出来的。总而言之,这个阶段,你需要做的是深入了解Java底层和Java类库(比如并发那本书就是Java并发包java.concurrent的内容),也就是JVM和JDK的相关内容。而且还要更深入的去了解你所使用的框架,方式比较推荐看源码或者看官方文档。另外,还有一种学习的方式,在2年这个阶段,也应该启用了,那就是造轮子。不要听信那套“不要重复造轮子”的论调,那是公司为了节省时间成本编造出来的。重复造轮子或许对别人没有价值,因为你造的轮子可能早就有了,而且一般情况下你造出来的轮子还没有现存的好。  但是对别人没有价值,不代表对你自己没有价值。一个造轮子的过程,是一个从无到有的过程。这个过程可以对你进行系统的锻炼,它不仅考察你的编码能力,还考察你的框架设计能力,你需要让你的轮子拥有足够好的扩展性、健壮性。而且在造轮子的过程中,你会遇到各种各样的难题,这些难题往往又是你学习的契机。当你把轮子造好的时候,你一定会发现,其实你自己收获了很多。所以,这个阶段,除了上面提到的了解JVM、JDK和框架源码以外,也请你根据别人优秀的源码,去造一个任何你能够想象出来的轮子。第四部分:参加工作3年到4年的同学这个阶段的同学,提升已经是很难了,而且这个阶段的学习往往会比较多样化。因为在前3年的过程中,你肯定或多或少接触过一些其它的技术,比如大数据、分布式缓存、分布式消息服务、分布式计算、软负载均衡等等。这些技术,你能精通任何一项,都将是你未来面试时巨大的优势,因此如果你对某一项技术感兴趣的话,  这个时候可以深入去研究一下。这项技术不一定是你工作所用到的,但一定是相关的。而且在研究一门新技术时,切忌朝三暮四。有的同学今天去整整大数据,搞搞Hadoop、hbase一类的东西。过不了一段时间,就觉得没意思,又去研究分布式缓存,比如redis。然后又过不了一段时间,又去研究分布式计算,比如整整Mapreduce或者storm。结果到最后,搞得自己好像什么都会一样,在简历上大言不惭的写上大数据、分布式缓存、分布式计算都了解,其实任何一个都只是浮于表面。到时候面试官随便一问,就把你给识破了。我比较推崇的基础书籍有三本,分别是《深入理解计算机系统》,《tcp/ip详解 卷一、二、三》,《数据结构与算法》。其中TCP/IP有三本书,但我们这里把这三本看成是一本大书。这三本分别适合三种人,《深入理解计算机系统》比较适合一直从事Java Web开发和APP后端开发工作的人群。《tcp/ip详解 卷一、二、三》比较适合做网络编程的人群,比如你使用netty去开发的话,那么就要对TCP/IP有更深入的了解。而《数据结构与算法》这本书,则比较适合做计算研究工作的人,比如刚才提到的分布式计算。另外,我要强调的是,这里所说的适合,并不是其它两本对你就没有用。比如你做Java Web和APP后端开发,《tcp/ip详解 卷一、二、三》这本书对你的作用也是很大的。这里只是分出个主次关系而已,你要是时间足够的话,能把三本都精读那当然最好不过了。第五部分:参加工作4年到5年的同学经过前面一年的历练,相信你在自己所钻研的领域已经有了自己一定的见解,这个时候,技术上你应该已经遇到瓶颈了。这个时候不要着急提高自己的技术,已经是时候提高你的影响力了,你可以尝试去一些知名的公司去提高你的背景,你可以发表一些文章去影响更多的人。当然,你也可以去Github创建一个属于你的开源项目,去打造自己的产品。  这次的开源项目不同于之前的造轮子,你这个时候是真的要去尽量尝试造出来真正对别人有价值的轮子。技术学到这个阶段,很容易遇到瓶颈,而且往往达到一定程度后,你再深入下去的收效就真的微乎其微了,除非你是专门搞学术研究的。然而很可惜,大部分程序猿做不到这一步,那是科学家做的事情。这个时候提高影响力不仅仅是因为技术上容易遇到瓶颈,更多的是影响力可以给你创造更多的机会。程序猿在某种程度上和明星很像,一个好的电视剧和电影就可以成就一批明星,程序猿有的时候也是,一个好的项目就可以成就一群程序猿。比如国内几个脍炙人口的项目,像淘宝、支付宝、QQ、百度、微信等等。这每一个项目,都成就了一批程序猿。我敢说,这里面任何一个项目,如果你是它的核心开发,光是这样一个Title,就已经是你非常大的优势。更何况还不止如此,Title说到底也是个名头,更重要的是,这种项目在做的时候,对你的历练一定也是非常给力的。
hiekay 2019-12-02 01:40:04 0 浏览量 回答数 0

问题

dubbo 支持的通信协议?有哪些序列化协议?说下 Hessian 的数据结构?【Java问答】48

面试题 dubbo 支持哪些通信协议?支持哪些序列化协议?说一下 Hessian 的数据结构?PB 知道吗?为什么 PB 的效率是最高的? 面试官心理分析 上一个问...
剑曼红尘 2020-07-01 15:18:43 7 浏览量 回答数 1

回答

一般用的是oauth2方式, 后台返回token时, 可自行设置token过期时间, 通常来说, 也会附带一个refresh_token字段. 当你上面获取的token过期时, 可refresh_token重新获取token而不用再次验证用户名及密码. 可参考下面: http://tools.ietf.org/html/rfc6749 ######我一直记得OAuth是一种用户可以不告知服务A其在服务B上的用户名和密码却可以在服务A上安全的使用服务B的一种认证方式? 用OAuth2是基于哪方面考虑的?是因为有refresh_token还是OAuth已经不单单局限于安全使用第三方资源这种形式了呢?###### http://my.oschina.net/kaster/blog/130861 参考本篇,和其他相关文章 客户端一般不会缓存密码一类的东西,我们是缓存 openid和token ######回复 @徐牛 : openid和TokenKey时效很长,未来客户端无须登录,直接调用响应的接口,服务端会验签,无效会返回登录超时。######文章很好,但是没有讨论到如何避免需要经常登录的问题? 是tokenKey会长期有效吗?###### 客户端本身网络稳定性差,有些Session框架在网络切换后,Session失效。 我们没有使用传统框架的Session机制,主要是和后台分布式的部署有关系。 接口方面,我们就是使用restful请求接口,接入层的分发服务器并不验证Session,只负责分发,真正的后台接口会自己来验证Session的有效性,对于分布在不同设备和进程的应用,使用Redis来缓存Session信息。 ######自己做是最终方案,而自己做授权系统这块要设计到加密算法,session,角色管理等等,我们这边开发力量不够。所以想看看有没有合适的框架。 不知道Srping secure等有没有这方面的优化。######求解答###### stateless ###### 类似的问题我也问过 作为第三方登陆,基本上是遵循oauth2 作为自己的用户登陆,我方案是结合两者优点,用token加用户名,不用session,哦我做的是ios开发,安卓不知道,还有人告诉我用心跳包的方式保持类似session的功能,因为移动端不知道什么时候就离开了,每隔多少时间发个包,表明存在,我觉得太麻烦了呵呵。 ######我感觉Session是一种比较简化的token不管是你自己用token还是session都绕不过我提的问题。 心跳是在长连接中才需要考虑的吧。
kun坤 2020-06-03 14:07:38 0 浏览量 回答数 0
阿里云企业服务平台 陈四清的老板信息查询 上海奇点人才服务相关的云产品 爱迪商标注册信息 安徽华轩堂药业的公司信息查询 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 天籁阁商标注册信息 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 北京芙蓉天下的公司信息查询