工程数据处理出问题什么情况

这几个问题回答起来没什么意思，我主要分析分析面试官为什么问你这几个问题。问题 1 主要应该是想了解你对调用其他程序或接口时出现的异常情况是如何处理的，毕竟程序的运行并不总是一帆风顺，如果由于其他的接口出现了问题，而你没有处理好这些问题继而引发你写的程序出错或崩溃，那确实不是一个优秀的程序员所做的。程序员不仅应该了解用户按常理出牌，按既定路线完成程序的情况，还应该做好发生各种异常情况的处理。问题 2 主要应该是想了解你是怎样评估你写的程序的，是通过怎样的手段了解的程序的运行情况，是如何优化你的程序的。实现功能并不是程序员的唯一目标，在实现功能的情况下做一个优秀的、高效的程序也是一项艰巨的工程。问题 3 主要应该是想了解你对程序体系结构，或者说是架构的理解，程序不是简单的代码堆积，是有思想线路支撑，有模块协作分工的。作为程序员，虽然可能不会去实际写某一块的东西，但是至少应该了解这些模块的功能以及所有模块之间的联系和他们是如何协作工作的。就好比实现一个接口，你需要处理输入，进行逻辑判断，数据库操作，遇到错误的响应，返回结果等等，这里每一块都是相当细致的。

抽象成数学问题： 明确问题是进行机器学习的第一步。机器学习的训练过程通常都是一件非常耗时的事情，胡乱尝试时间成本是非常高的。这里的抽象成数学问题，指的我们明确我们可以获得什么样的数据，目标是一个分类还是回归或者是聚类的问题，如果都不是的话，如果划归为其中的某类问题。 获取数据： 数据决定了机器学习结果的上限，而算法只是尽可能逼近这个上限。数据要有代表性，否则必然会过拟合。而且对于分类问题，数据偏斜不能过于严重，不同类别的数据数量不要有数个数量级的差距。而且还要对数据的量级有一个评估，多少个样本，多少个特征，可以估算出其对内存的消耗程度，判断训练过程中内存是否能够放得下。如果放不下就得考虑改进算法或者使用一些降维的技巧了。如果数据量实在太大，那就要考虑分布式了。 特征预处理与特征选择： 良好的数据要能够提取出良好的特征才能真正发挥效力。特征预处理、数据清洗是很关键的步骤，往往能够使得算法的效果和性能得到显著提高。归一化、离散化、因子化、缺失值处理、去除共线性等，数据挖掘过程中很多时间就花在它们上面。这些工作简单可复制，收益稳定可预期，是机器学习的基础必备步骤。筛选出显著特征、摒弃非显著特征，需要机器学习工程师反复理解业务。这对很多结果有决定性的影响。特征选择好了，非常简单的算法也能得出良好、稳定的结果。这需要运用特征有效性分析的相关技术，如相关系数、卡方检验、平均互信息、条件熵、后验概率、逻辑回归权重等方法。 训练模型与调优： 直到这一步才用到我们上面说的算法进行训练。现在很多算法都能够封装成黑盒供人使用。但是真正考验水平的是调整这些算法的（超）参数，使得结果变得更加优良。这需要我们对算法的原理有深入的理解。理解越深入，就越能发现问题的症结，提出良好的调优方案。 模型诊断：如何确定模型调优的方向与思路呢？这就需要对模型进行诊断的技术。过拟合、欠拟合判断是模型诊断中至关重要的一步。常见的方法如交叉验证，绘制学习曲线等。过拟合的基本调优思路是增加数据量，降低模型复杂度。欠拟合的基本调优思路是提高特征数量和质量，增加模型复杂度。误差分析 也是机器学习至关重要的步骤。通过观察误差样本，全面分析误差产生误差的原因：是参数的问题还是算法选择的问题，是特征的问题还是数据本身的问题。诊断后的模型需要进行调优，调优后的新模型需要重新进行诊断，这是一个反复迭代不断逼近的过程，需要不断地尝试， 进而达到最优状态。 模型融合： 一般来说，模型融合后都能使得效果有一定提升。而且效果很好。工程上，主要提升算法准确度的方法是分别在模型的前端（特征清洗和预处理，不同的采样模式）与后端（模型融合）上下功夫。因为他们比较标准可复制，效果比较稳定。而直接调参的工作不会很多，毕竟大量数据训练起来太慢了，而且效果难以保证。 上线运行：这一部分内容主要跟工程实现的相关性比较大。工程上是结果导向，模型在线上运行的效果直接决定模型的成败。 不单纯包括其准确程度、误差等情况，还包括其运行的速度(时间复杂度)、资源消耗程度（空间复杂度）、稳定性是否可接受。这些工作流程主要是工程实践上总结出的一些经验。并不是每个项目都包含完整的一个流程。这里的部分只是一个指导性的说明，只有大家自己多实践，多积累项目经验，才会有自己更深刻的认识。

算法是比较复杂又基础的学科，每个学编程的人都会学习大量的算法。而根据统计，以下这18个问题是面试中最容易遇到的，本文给出了一些基本答案，供算法方向工程师或对此感兴趣的程序员参考。 1)请简单解释算法是什么? 算法是一个定义良好的计算过程，它将一些值作为输入并产生相应的输出值。简单来说，它是将输入转换为输出的一系列计算步骤。 2)解释什么是快速排序算法? 快速排序算法能够快速排序列表或查询。它基于分割交换排序的原则，这种类型的算法占用空间较小，它将待排序列表分为三个主要部分： ·小于Pivot的元素 ·枢轴元素Pivot(选定的比较值) ·大于Pivot的元素 3)解释算法的时间复杂度? 算法的时间复杂度表示程序运行完成所需的总时间，它通常用大O表示法来表示。 4)请问用于时间复杂度的符号类型是什么? 用于时间复杂度的符号类型包括： ·Big Oh：它表示小于或等于目标多项式 ·Big Omega：它表示大于或等于目标多项式 ·Big Theta：它表示与目标多项式相等 ·Little Oh：它表示小于目标多项式 ·Little Omega：它表示大于目标多项式 5)解释二分法检索如何工作? 在二分法检索中，我们先确定数组的中间位置，然后将要查找的值与数组中间位置的值进行比较，若小于数组中间值，则要查找的值应位于该中间值之前，依此类推，不断缩小查找范围，直至得到最终结果。 6)解释是否可以使用二分法检索链表? 由于随机访问在链表中是不可接受的，所以不可能到达O(1)时间的中间元素。因此，对于链表来说，二分法检索是不可以的(对顺序链表或排序后的链表是可以用的)。 7)解释什么是堆排序? 堆排序可以看成是选择排序的改进，它可以定义为基于比较的排序算法。它将其输入划分为未排序和排序的区域，通过不断消除最小元素并将其移动到排序区域来收缩未排序区域。 8)说明什么是Skip list? Skip list数据结构化的方法，它允许算法在符号表或字典中搜索、删除和插入元素。在Skip list中，每个元素由一个节点表示。搜索函数返回与key相关的值的内容。插入操作将指定的键与新值相关联，删除操作可删除指定的键。 9)解释插入排序算法的空间复杂度是多少? 插入排序是一种就地排序算法，这意味着它不需要额外的或仅需要少量的存储空间。对于插入排序，它只需要将单个列表元素存储在初始数据的外侧，从而使空间复杂度为O(1)。 10)解释什么是“哈希算法”，它们用于什么? “哈希算法”是一个哈希函数，它使用任意长度的字符串，并将其减少为唯一的固定长度字符串。它用于密码有效性、消息和数据完整性以及许多其他加密系统。 11)解释如何查找链表是否有循环? 要知道链表是否有循环，我们将采用两个指针的方法。如果保留两个指针，并且在处理两个节点之后增加一个指针，并且在处理每个节点之后，遇到指针指向同一个节点的情况，这只有在链表有循环时才会发生。 12)解释加密算法的工作原理? 加密是将明文转换为称为“密文”的密码格式的过程。要转换文本，算法使用一系列被称为“键”的位来进行计算。密钥越大，创建密文的潜在模式数越多。大多数加密算法使用长度约为64到128位的固定输入块，而有些则使用流方法。 13)列出一些常用的加密算法? 一些常用的加密算法是： ·3-way ·Blowfish ·CAST ·CMEA ·GOST ·DES 和Triple DES ·IDEA ·LOKI等等 14)解释一个算法的最佳情况和最坏情况之间有什么区别? ·最佳情况：算法的最佳情况解释为算法执行最佳的数据排列。例如，我们进行二分法检索，如果目标值位于正在搜索的数据中心，则这就是最佳情况，最佳情况时间复杂度为0。 ·最差情况：给定算法的最差输入参考。例如快速排序，如果选择关键值的子列表的最大或最小元素，则会导致最差情况出现，这将导致时间复杂度快速退化到O(n2)。 15)解释什么是基数排序算法? 基数排序又称“桶子法”，是通过比较数字将其分配到不同的“桶里”来排序元素的。它是线性排序算法之一。 16)解释什么是递归算法? 递归算法是一个解决复杂问题的方法，将问题分解成较小的子问题，直到分解的足够小，可以轻松解决问题为止。通常，它涉及一个调用自身的函数。 17)提到递归算法的三个定律是什么? 所有递归算法必须遵循三个规律： ·递归算法必须有一个基点 ·递归算法必须有一个趋向基点的状态变化过程 ·递归算法必须自我调用 18)解释什么是冒泡排序算法? 冒泡排序算法也称为下沉排序。在这种类型的排序中，要排序的列表的相邻元素之间互相比较。如果它们按顺序排列错误，将交换值并以正确的顺序排列，直到最终结果“浮”出水面。 满意记得采纳哈

有编程能力和数据挖掘能力的工程师最火，包括：数据挖掘工程师、机器学习工程师，算法工程师。 今年3月份时，谷歌开发的人工智能AlphaGo打败了全球最顶尖的围棋高手，轰动全世界，AI时代正式拉开序幕。实际上，人工智能这一概念早在上世纪一大批科幻小说陆续发表时，就已被人们接受，而随着科技的发展，人工智能的发展前景更是日益清晰。一个人工智能的诞生需要无数个工程师挥洒汗水。其中，负责开发学习算法、使机器能像人类一样思考问题的数据挖掘工程师更是无比重要。什么人能完成人工智能的开发任务呢。必须指出，人工智能和一般的计算机程序有极大的差别，它应当具有“能够自主学习知识”这一特点，这一特点也被称为“机器学习”。而自学习模型(或者说机器学习能力开发)正是数据挖掘工程师的强项，人工智能的诞生和普及需要一大批数据挖掘工程师。  那么在AI时代，如何才能掌握相关的技能，成为企业需要的数据挖掘人才呢。 第一个门槛是数学 首先，机器学习的第一个门槛是数学知识。机器学习算法需要的数学知识集中在微积分、线性代数和概率与统计当中，具有本科理工科专业的同学对这些知识应该不陌生，如果你已经还给了老师，我还是建议你通过自学或大数据学习社区补充相关知识。所幸的是如果只是想合理应用机器学习算法，而不是做相关方向高精尖的研究，需要的数学知识啃一啃教科书还是基本能理解下来的。 第二个门槛是编程 跨过了第一步，就是如何动手解决问题。所谓工欲善其事必先利其器，如果没有工具，那么所有的材料和框架、逻辑、思路都给你，也寸步难行。因此我们还是得需要合适的编程语言、工具和环境帮助自己在数据集上应用机器学习算法。对于有计算机编程基础的初学者而言，Python是很好的入门语言，很容易上手，同时又活跃的社区支持，丰富的工具包帮助我们完成想法。没有编程基础的同学掌握R或者平台自带的一些脚本语言也是不错的选择。 Make your hands dirty 接下来就是了解机器学习的工作流程和掌握常见的算法。一般机器学习步骤包括： 数据建模：将业务问题抽象为数学问题； 数据获取：获取有代表性的数据，如果数据量太大，需要考虑分布式存储和管理； 特征工程：包括特征预处理与特征选择两个核心步骤，前者主要是做数据清洗，好的数据清洗过程可以使算法的效果和性能得到显著提高，这一步体力活多一些，也比较耗时，但也是非常关键的一个步骤。特征选择对业务理解有一定要求，好的特征工程会降低对算法和数据量的依赖。 模型调优：所谓的训练数据都是在这个环节处理的，简单的说就是通过迭代分析和参数优化使上述所建立的特征工程是最优的。 这些工作流程主要是工程实践上总结出的一些经验。并不是每个项目都包含完整的一个流程，只有大家自己多实践，多积累项目经验，才会有自己更深刻的认识。 翻过了数学和编程两座大山，就是如何实践的问题，其中一个捷径就是积极参加国内外各种数据挖掘竞赛。国外的Kaggle和国内的阿里天池比赛都是很好的平台，你可以在上面获取真实的数据和队友们一起学习和进行竞赛，尝试使用已经学过的所有知识来完成这个比赛本身也是一件很有乐趣的事情。 另外就是企业实习，可以先从简单的统计分析和数据清洗开始做起，积累自己对数据的感觉，同时了解企业的业务需求和生产环境。我们通常讲从事数据科学的要”Make your hands dirty”，就是说要通过多接触数据加深对数据和业务的理解，好厨子都是食材方面的专家，你不和你的“料”打交道，怎么能谈的上去应用好它。 摆脱学习的误区 初学机器学习可能有一个误区，就是一上来就陷入到对各种高大上算法的追逐当中。动不动就讨论我能不能用深度学习去解决这个问题啊。实际上脱离业务和数据的算法讨论是毫无意义的。上文中已经提到，好的特征工程会大大降低对算法和数据量的依赖，与其研究算法，不如先厘清业务问题。任何一个问题都可以用最传统的的算法，先完整的走完机器学习的整个工作流程，不断尝试各种算法深挖这些数据的价值，在运用过程中把数据、特征和算法搞透。真正积累出项目经验才是最快、最靠谱的学习路径。 自学还是培训 很多人在自学还是参加培训上比较纠结。我是这么理解的，上述过程中数学知识需要在本科及研究生阶段完成，离开学校的话基本上要靠自学才能补充这方面的知识，所以建议那些还在学校里读书并且有志于从事数据挖掘工作的同学在学校把数学基础打好，书到用时方恨少，希望大家珍惜在学校的学习时间。 除了数学以外，很多知识的确可以通过网络搜索的方式自学，但前提是你是否拥有超强的自主学习能力，通常拥有这种能力的多半是学霸，他们能够跟据自己的情况，找到最合适的学习资料和最快学习成长路径。如果你不属于这一类人，那么参加职业培训也许是个不错的选择，在老师的带领下可以走少很多弯路。另外任何学习不可能没有困难，也就是学习道路上的各种沟沟坎坎，通过老师的答疑解惑，可以让你轻松迈过这些障碍，尽快实现你的“小”目标。 机器学习这个领域想速成是不太可能的，但是就入门来说，如果能有人指点一二还是可以在短期内把这些经典算法都过一遍，这番学习可以对机器学习的整体有个基本的理解，从而尽快进入到这个领域。师傅领进门，修行靠个人，接下来就是如何钻进去了，好在现在很多开源库给我们提供了实现的方法，我们只需要构造基本的算法框架就可以了，大家在学习过程中应当尽可能广的学习机器学习的经典算法。 学习资料 至于机器学习的资料网上很多，大家可以找一下，我个人推荐李航老师的《统计机器学习》和周志华老师的《机器学习》这两门书，前者理论性较强，适合数学专业的同学，后者读起来相对轻松一些，适合大多数理工科专业的同学。

“程序设计 = 算法 + 数据结构”是瑞士计算机科学家Niklaus Wirth于1976年出版的一本书的书名，很快就成了在计算机工作者之间流传的一句名言。斗转星移，尽管新技术方法不断涌现，这句名言依然焕发着无限的生命力，它借助面向对象知识的普及，使数据结构技术更加完善和易于使用。由此，也说明了数据结构在计算机学科中的地位和不可替代的独特作用。 然而，在可视化程序设计的今天，借助于集成开发环境我们可以很方便、快捷地开发部署应用程序，程序设计似乎不再只是计算机专业的人员的专利，很多人以为，只要掌握了几种开发工具就可以成为编程高手了，其实这是一个误区。纵然，我们可以很熟练地掌握一门程序设计语言、熟练地运用各种IDE开发应用程序，但是我们写出的代码是否是优良的。我们的设计是否合理。代码执行是否是高效的。代码风格是否是有美感的。更甚的说我们所写出代码的是否是艺术。 在长达几年的时间内，我总是陷在了一个误区里面：即认为工程能力和算法能力是不相干的两回事，我们似乎可以很轻松地完成一个工程项目，至少我在做一些MIS系统的时候一直都是这么认为的，甚至觉得根本不需要所谓的算法或数据结构。当时一直想不通的是为什么Google、百度这样牛的公司却对ACMer们如此青睐，对于这种招聘的标准感到疑惑不解。为什么他们不在技术（多线程、网络编程、分布式系统等）上做要求，却偏偏只关注这么一小块的算法设计。 我曾经反复地告诉自己“程序设计 = 算法 + 数据结构”在70年代提出是受限于计算机硬件，当时的内存不足、计算能力不强，程序需要设计足够精巧细致。再看当前主流的计算机配置，比70年代的大型机运算能力还要强大，我们好像完全不用担心算法设计的问题。报着这样的想法，我向来都不太重视算法，而且工程中对算法的需求并不多。 只是有一天，我突然发现我只是片面地关注其中一个方面，硬件能力是提升了，但同时人们所面对的信息、数据、运算任务的规模也是极大的膨胀了，而且膨胀的规模比硬件本身运算能力提升的规模还要大很多。算法和数据结构不仅没有贬值，反而比之前那个时代显得更为重要。试想，在互联网迅猛发展的今天，一个中等规模的企业每天所产生的数据量能达到GB级甚至TB级。要处理这样的海量数据不是说单纯的硬件运算能力上来就解决了的，设计优良的算法和数据结构设计能够在1分钟之内完成任务，而一个糟糕的设计则可能需要1个小时的运行。 一般认为，一个数据结构是由数据元素依据某种逻辑联系组织起来的，这种对数据元素间逻辑关系的描述称为数据结构。许多大型系统的构造经验表明，系统实现的困难程度和系统构造的质量都严重的依赖于是否选择了最优的数据结构。许多时候，确定了数据结构后，算法就容易得到了。当然，有些情况下事情也会反过来，我们根据特定算法来选择数据结构与之适应。算法则可以理解为有基本运算及规定的运算顺序所构成的完整的解题步骤，或者看成按照要求设计好的有限的确切的计算序列，并且这样的步骤和序列可以解决一类问题。 总的来说，数据结构和算法并不是一门教你编程的课，它们可以脱离任何的计算机程序设计语言，而只需要从抽象意义上去概括描述。说的简单一点，数据结构是一门告诉你数据在计算机里如何组织的课程，而算法是一门告诉你数据在计算机里如何运算的课程，前者是结构学、后者是数学。程序设计就像盖房子，数据结构是砖、瓦，而算法则是设计图纸。你若想盖房子首先必须要有原材料（数据结构），但这些原材料并不能自动地盖起你想要的房子，你必须按照设计图纸（算法）一砖一瓦地去砌，这样你才能拥有你想要的房子。数据结构是程序设计这座大厦的基础，没有基础，无论设计有多么高明，这座大厦不可能建造起来。算法则是程序设计之灵魂，它是程序设计的思想所在，没有灵魂没有思想那不叫程序，只是一堆杂乱无章的符号而已。在程序设计中，数据结构就像物质，而算法则是意识，这在哲学上可以理解为：意识是依赖与物质而存在的，物质是由意识而发展的。双方相互依赖，缺一不可。 当然最经典的数据结构是有限的，包括线性表、栈、队列、串、数组、二叉树、树、图、查找表等，而算法则是琳琅满目的，多种多样的。就好像数据结构是人体的各种组织、器官，算法则是人的思想。你可以用自己的思想去支配你的身体各个可以运动的器官随意运动。如果你想吃苹果，你可以削皮吃，可以带皮吃，只要你愿意，甚至你可以不洗就吃。但无论如何，你的器官还是你的器官，就那么几样，目的只有一个就是吃苹果，而方式却是随心所欲的。这就是算法的灵活性、不固定性。因此可以这样说：数据结构是死的，而算法是活的。 我花了四年时间才走出这个误区，值得庆幸的是不算太晚，而我的梦想是要做一名优秀的架构师，缺乏数据结构和算法的深厚功底，很难设计出高水平的具有专业水准的架构和应用，数据结构和算法则是我实现梦想最坚实的基石。现在，也正是我需要开始沉淀的时刻。程序设计这项伟大的工程，教授于我的将不仅仅是技术这么简单，我期待它能给我以更深的思考与感悟，激发我对生命的热爱，对理想的执着，对卓越的追求。

在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，分成以下 6 种解决方案。（一）规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。优点：解决（规避）了分布式事务。缺点：显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。由于这个方法存在明显缺点，通常不建议使用。（二）经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。eBay 方式的主要思路如下。Base：一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。（三）去哪儿网分布式事务方案随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢？最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过，使用异步消息 Consumer 端需要实现幂等。幂等有两种方式，一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：重试 B，直到 B 成功，事务记录表里记录了各项调用参数等信息；执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。总结起来，其实两种方式的根本原理是类似的，也就是将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性。（四）蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？方案选型服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性，所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦，通过订阅方消费 MQ 消息时的 ACK 机制，保证消息一定消费成功，达到最终一致性。由于消息可能会被重发，消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。我们在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。（五）支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。主要思路如下，大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说，DTS 框架有如下特性：最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。协议简单：DTS 定义了类似 2PC 的标准两阶段接口，业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上，与底层协议无关。与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的 confirm 操作，在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较，没有单独的 Prepare 阶段，降低协议成本。系统故障容忍度高，恢复简单（六）农信网数据一致性方案电商业务公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说，电商部门的订单支付，需要调用支付平台的支付接口来处理订单；同时需要调用积分中心的接口，按照业务规则，给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。用户信息变更公司的用户信息，统一由用户中心维护，而用户信息的变更需要同步给各业务子系统，业务子系统再根据变更内容，处理各自业务。用户中心作为 MQ 的 producer，添加通知给 MQ。APP Server 订阅该消息，同步本地数据信息，再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制，目前主要使用 ActiveMQ，基于 Virtual Topic 的订阅方式，保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。

一、基础篇 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、软实力 说说你的优缺点、亮点 说说你最近在看什么书、什么博客、在研究什么新技术、再看那些开源项目的源代码 说说你觉得最有意义的技术书籍 工作之余做什么事情、平时是如何学习的，怎样提升自己的能力 说说个人发展方向方面的思考 说说你认为的服务端开发工程师应该具备哪些能力 说说你认为的架构师是什么样的，架构师主要做什么 如何看待加班的问题

怎么 没人来呀 @中山野鬼###### 1、如果想去掉while（true），可以考虑通知实现； 2、关于自动重连的问题，可以考虑重发送逻辑中抽离出来，采用心跳检测完成； 3、另外发送速率统计部分也应该抽离出来。 4、上多通道要考虑资源使用可控。 5、实在不行按照业务拆分成多模块，用redis 或mq类的扩展一下架构设计； ######回复 @OS小小小 : map =(Map)JSONObject.parse(SendMsgCMPP2ThredPoolByDB.ZhangYi.take()); 换成take，阻塞线程，试试。######回复 @OS小小小 : 1、通知只是告知队列里有新的数据需要处理了； 5、内存队列换成redis队列 实现成本增加，但是可扩展性增加；######1、通知实现的话 ，岂不是 无法保证 最少发送么，又会陷入另一个问题中 是吗？ 或者是我的想法不对么？ 2、嗯，这一块可以这样做。谢谢你 3、速率统计这里 我目前想不到怎么抽离、既可以控制到位，又可以保证不影响。。。 5、redis 是有的 但是 redis的队列的话 跟我这个 没啥区别吧，可能速度更快一点。######while(true) 里面 没数据最起码要休眠啊，不停死循环操作，又没有休眠cpu不高才怪######回复 @OS小小小 : 休眠是必须的，只是前面有数据进来，可以用wait notify 的思路通知，思路就是这样，CountDownLatch 之类多线程通讯也可以实现有数据来就能立即处理的功能######嗯，目前在测试 排除没有数据的情况，所以这一块没有去让他休眠，后面会加进去。 就针对于目前这种情况，有啥好办法吗###### 我的思路是：一个主线程，多个任务子线程。 主线程有一层while(true)，这个循环是不断的扫描LinkedBlockingQueue是否有数据，有则交个任务子线程（也就是你这里定义的线程池）处理，而不是像你这样每个子任务线程都有一个while(true) ######这才是对的做法######嗯，这思路可以。谢谢哈###### 引用来自“K袁”的评论 我的思路是：一个主线程，多个任务子线程。 主线程有一层while(true)，这个循环是不断的扫描LinkedBlockingQueue是否有数据，有则交个任务子线程（也就是你这里定义的线程池）处理，而不是像你这样每个子任务线程都有一个while(true) 正确做法. 还有就是 LinkedBlockingQueue 本身阻塞的，while(true)没问题，主要在于不需要每个发送线程都去block######while（true）不加休眠就会这样###### java 的线程数量大致要和cpu数量一致，并不是越多越快，线程调度是很消耗时间的。要用好多线程，就需要设计出好的多线程业务模型，不恰当的sleep和block是性能的噩梦。利用好LinkedBlockingQueue，队列空闲时读队列的线程会释放cpu。利用消息触发后续线程工作，就没必要使用while(true)来不停的扫描。 ######@蓝水晶飞机 看到你要比牛逼，我就没有兴趣跟你说话了######回复 @不日小鸡 : 我就是装逼怎么啦，特么的装逼装出样子来的，起码也比你牛逼啊。######回复 @蓝水晶飞机 : 你说这话不能掩盖你没有回复我的问题又来回复我导致装逼失败的事实。 那你不是楼主你回复我干什么，还不是回答我的问题。 不要装逼了好么，装多就成傻逼了######回复 @不日小鸡 : 此贴楼主不是你，装什么逼。######回复 @王斌_ : 这些我都知道，我的意思是你这样回复可能会误导其他看帖子的人或者新手，让他们以为线程数就等于CPU数###### 引用来自“OS小小小”的评论 怎么 没人来呀 @中山野鬼 抬举我了。c++ 我还敢对不知深浅的人说，“权当我不懂”，java真心只是学过，没有实际工程上的经验。哈。而且我是c的思维，面对c适合的应用开发，是反对使用线程的。基本思维是，执行模块的生命周期不以任务为决定，同类的执行模块，可根据物理硬核数量，形成对应独立多个进程，但绝对不会同类的任务独立对应多个线程。哈。所以java这类面向线程的设计，没办法参与讨论。设计应用目标不同，系统组织策略自然有异。 唯一的建议是：永远不要依赖工具，特别是所谓的垃圾资源处理回收机制，无论它做的再好，一旦你依赖，必然你的代码，在不久的将来会因为系统设计规模的变大，而变的垃圾。哈。 听不懂的随便喷，希望听懂的，能记得这个观点，这不是我一个人的观点。 ######给100万像素做插值运算进行染色特效，请问单线程怎么做比多线程快？###### @乌龟壳 : 几种方法都可以，第一是按照计算步骤，每个进程处理一个步骤，然后切换共享空间（这没有数据传递逻辑上的额外开销），就是流水思维。第二个是block的思维，同样的几个进程负责相同计算，但负责不同片区。同时存在另一类的进程是对前期并发处理完的工作进行边界处理。 你这个例子体现不出进程和线程的差异的。 如果非要考虑进程和线程在片内cache的差异，如果没记错（错了大家纠正哈），进程之间的共享是在二级缓存之间吧。即便线程能做到一级缓存之间的共享，但对于这种大批量像素的计算，用进程仍然是使用 dma，将数据成块载入一级缓存区域进行处理，而这个载入工作和计算工作是同步的。不会有额外太多的延迟。 你举的这个例子，还真好是我以前的老本行。再说了。像素计算，如今都用专用计算处理器了吧。还用x86或arm来处理，不累死啊。哈。 而且这种东西java不适合，同样的处理器，用c写，基本可以比java快1到2倍。因为c可以直接根据硬件特性和计算逻辑特点有效调度底层硬件驱动方式。而java即便你用了底层优化的官方库，仍然不能保证硬件与计算目标特性的高度整合。 ######回复 @中山野鬼 : 简单来说，你的多个进程处理结果进行汇总的时候，是不是要做内存复制操作？如果是多线程天然就不用，多进程用系统的共享内存机制也不用，问题是既然用了共享内存，和多线程就没区别了。######回复 @乌龟壳 : 两回事哦。共享空间是独立的，而线程如果我没记错，全局变量，包括文件内的（静态变量）是共享的。不同线程共享同一个进程内的变量嘛。这些和业务逻辑相关的东西，每个线程又是独立一套业务逻辑，针对c语言，这样去设计，不是没事找事嘛。面向对象语言，这块都帮你处理好了，自然没有关系。######既然有共享空间了，那你所说的进程和线程实际就是一回事了。###### @乌龟壳   ，数据分两种，一种和算法或处理相关的。一种是待处理的数据。 前者，不应该共享，后者属于数据加工流程，必然存在数据传递或流动，最低成本的传递／流动方式就是共享内存，交替使用权限的思路。 但这仅仅针对待加工的数据和辅助信息，而不针对程序本身。 进程不会搞混乱这些东西特别是（待加工数据的辅助信息），而线程，就各种乱吧。哈。 进程之间，虽然用共享空间，但它本质是数据传递／流动，当你采用多机（物理机器）并发处理时，进程移动到另外一个物理主机，则共享空间就是不能选择的传递／流动方式了。但线程就没有这些概念。 ######回复 @中山野鬼 : 是啊，java天然就不是像C一样对汇编的包装。######@乌龟壳 面向企业级的各种业务，java这些没问题的。而且更有优势，面向计算设备特性的设计开发，就不行了。哈。######回复 @中山野鬼 : 也算各有场景吧，java同样可以多进程可以分布式来降低多线程的风险。java也可以静态编译成目标机器码。总之事在人为。######回复 @乌龟壳 : 高手，啥都可以，低手，依赖这些，就是各种想当然。哈哈。######回复 @中山野鬼 : 那针对java的垃圾回收，这个东西是可以调节它算法的，不算依赖工具吧，哈。不然依赖C语言语法也算依赖工具咯。哈。;-p

当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下： 限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。；读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读；缓存： 使用MySQL的缓存，另外对重量级、更新少的数据可以考虑使用应用级别的缓存； 还有就是通过分库分表的方式进行优化，主要有垂直分表和水平分表 垂直分区： 根据数据库里面数据表的相关性进行拆分。 例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。 简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。 如下图所示，这样来说大家应该就更容易理解了。 垂直拆分的优点： 可以使得行数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。 垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂； 垂直分表 把主键和一些列放在一个表，然后把主键和另外的列放在另一个表中 适用场景 1、如果一个表中某些列常用，另外一些列不常用 2、可以使数据行变小，一个数据页能存储更多数据，查询时减少I/O次数 缺点 有些分表的策略基于应用层的逻辑算法，一旦逻辑算法改变，整个分表逻辑都会改变，扩展性较差 对于应用层来说，逻辑算法增加开发成本 管理冗余列，查询所有数据需要join操作 水平分区： 保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。 水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。 水品拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以 水平拆分最好分库 。 水平拆分能够 支持非常大的数据量存储，应用端改造也少，但 分片事务难以解决 ，跨界点Join性能较差，逻辑复杂。 《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度 ，一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络I/O。 水平分表： 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询次数 适用场景 1、表中的数据本身就有独立性，例如表中分表记录各个地区的数据或者不同时期的数据，特别是有些数据常用，有些不常用。 2、需要把数据存放在多个介质上。 水平切分的缺点 1、给应用增加复杂度，通常查询时需要多个表名，查询所有数据都需UNION操作 2、在许多数据库应用中，这种复杂度会超过它带来的优点，查询时会增加读一个索引层的磁盘次数 下面补充一下数据库分片的两种常见方案： 客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。 中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。 分库分表后面临的问题 事务支持 分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。 跨库join 只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。 分库分表方案产品 跨节点的count,order by,group by以及聚合函数问题 这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。 数据迁移，容量规划，扩容等问题 来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。 ID问题 一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由. 一些常见的主键生成策略

API(Application Programming Interface,应用程序编程接口)是一套用来控制Windows的各个部件(从桌面的外观到为一个新进程分配的内存)的外观和行为的一套预先定义的Windows函数.用户的每个动作都会引发一个或几个函数的运行以告诉Windows发生了什么. 这在某种程度上很象Windows的天然代码.其他的语言只是提供一种能自动而且更容易的访问API的方法.VB在这方面作了很多工作.它完全隐藏了API并且提供了在Windows环境下编程的一种完全不同的方法. 这也就是说,你用VB写出的每行代码都会被VB转换为API函数传递给Windows.例如,Form1.Print...VB 将会以一定的参数(你的代码中提供的,或是默认参数)调用TextOut 这个API函数. 。同样,当你点击窗体上的一个按钮时,Windows会发送一个消息给窗体(这对于你来说是隐藏的),VB获取这个调用并经过分析后生成一个特定事件(Button_Click). API函数包含在Windows系统目录下的动态连接库文件中(如User32.dll,GDI32.dll,Shell32.dll...). API 声明 正如在"什么是API"中所说,API函数包含在位于系统目录下的DLL文件中.你可以自己输入API函数的声明,但VB提供了一种更简单的方法,即使用API Text Viewer. 要想在你的工程中声明API函数,只需运行API Text Viewer,打开Win32api.txt(或.MDB如果你已经把它转换成了数据库的话,这样可以加快速度.注:微软的这个文件有很多的不足,你可以试一下本站提供下载的api32.txt),选择"声明",找到所需函数,点击"添加(Add)"并"复制(Copy)",然后粘贴(Paste)到你的工程里.使用预定义的常量和类型也是同样的方法. 你将会遇到一些问题: 假设你想在你的窗体模块中声明一个函数.粘贴然后运行,VB会告诉你:编译错误...Declare 语句不允许作为类或对象模块中的 Public 成员...看起来很糟糕,其实你需要做的只是在声明前面添加一个Private(如 Private Declare Function...).--不要忘了,可是这将使该函数只在该窗体模块可用. 在有些情况下,你会得到"不明确的名称"这样的提示,这是因为函数.常量或其他的什么东西共用了一个名称.由于绝大多数的函数(也可能是全部,我没有验证过)都进行了别名化,亦即意味着你可以通过Alias子句使用其它的而不是他们原有的名称,你只需简单地改变一下函数名称而它仍然可以正常运行. API 分为四种类型： 远程过程调用（RPC）：通过作用在共享数据缓存器上的过程（或任务）实现程序间的通信。 标准查询语言（SQL）：是标准的访问数据的查询语言，通过通用数据库实现应用程序间的数据共享。 文件传输：文件传输通过发送格式化文件实现应用程序间数据共享。 信息交付：指松耦合或紧耦合应用程序间的小型格式化信息，通过程序间的直接通信实现数据共享。 当前应用于 API 的标准包括 ANSI 标准 SQL API。另外还有一些应用于其它类型的标准尚在制定之中。API 可以应用于所有计算机平台和操作系统。这些 API 以不同的格式连接数据（如共享数据缓存器、数据库结构、文件框架）。每种数据格式要求以不同的数据命令和参数实现正确的数据通信，但同时也会产生不同类型的错误。因此，除了具备执行数据共享任务所需的知识以外，这些类型的 API 还必须解决很多网络参数问题和可能的差错条件，即每个应用程序都必须清楚自身是否有强大的性能支持程序间通信。相反由于这种 API 只处理一种信息格式，所以该情形下的信息交付 API 只提供较小的命令、网络参数以及差错条件子集。正因为如此，交付 API 方式大大降低了系统复杂性，所以当应用程序需要通过多个平台实现数据共享时，采用信息交付 API 类型是比较理想的选择。 API 与图形用户接口（GUI）或命令接口有着鲜明的差别： API 接口属于一种操作系统或程序接口，而后两者都属于直接用户接口。 有时公司会将 API 作为其公共开放系统。也就是说，公司制定自己的系统接口标准，当需要执行系统整合、自定义和程序应用等操作时，公司所有成员都可以通过该接口标准调用源代码，该接口标准被称之为开放式 API。 da'an'lai'yu'na'w'n答案来源网络，供您参考

1.产品2.UI3.CSS4.JS5.后端（Java/php/python）6.DBA(mysql/oracle)7.运维（OP） 8.测试（QA）9.算法（分类/聚类/关系抽取/实体识别）10.搜索（Lucene/Solr/elasticSearch）11.大数据工程师（Hadoop）12.Android13.IOS14.运营 一.产品1 工作内容：了解用户需求，做竞品调研，画产品原型，写产品文档，讲解产品需求，测试产品Bug，收集用户反馈，苦练金刚罩以防止程序员拿刀砍。2 需要技能：PPT，Word, Axure,XP,MVP，行业知识，沟通。 二. UI1 工作内容：收到产品原型，给原型上色，偶尔会自作主张调整下原型的位置，出不同的风格给老板和客户选，然后听他们的意见给出一个自己极不喜欢的风格，最好给Android，IOS或者是CSS做好标注，还有的需要直接帮他们切好图，最后要练出来象素眼，看看这些不靠谱的程序员们有没有上错色或者是有偏差。2 需要技能：PS，Illustrator，Sketch，耐性，找素材。 三. CSS1 工作内容：产品设计好原型，UI做出来了效果图，剩下的就是CSS工程师用代码把静态文件写出来的。 2 需要技能：环境【IDE（WEBStorm，Sublime，EditPlus），源码管理（SVN/Git） ，WEB服务器(nginx)】基础【PS，域名，Html，Html5，CSS，CSS3】扩展【自适应，响应式，Bootstrap，Less，Flex】 四 .JS 1 工作内容：JS工程师其实分成两类，在之前讲CSS的时候已经提到过，一个是套页面的，一个是前后端分离的。对这两个概念还是分不太清的，可以回过头去看CSS的部分。 2 需要技能：环境【IDE（WEBStorm，Sublime，EditPlus），源码管理（SVN/Git） ，WEB服务器(nginx)】基础【Http，REST，跨域，语法，组件，F12，Json，Websocket】框架【JQuery，AngularJS，Bower，RequireJS，GruntJS，ReactJS，PhoneGap】业务【金融，教育，医疗，汽车，房产等等等等各种行业】 五 .后端（Java/python/go） 1 工作内容：大部分的后端工程师都停留在功能实现的层面上。这是现在国内二流或者是三流的公司的现状，甚至是在某些一流的公司。很多时候都是架构师出了架构设计，更多的外包公司根本就是有DBA来做设计，然后后端程序员从JS到CSS到Java全写，完全就是一个通道，所有的复杂逻辑全部交给DB来做，这也是几年前DBA很受重视的原因。 2 需要技能：环境【IDE（Idea/Eclipse，Maven，jenkins,Nexus,Jetty,Shell，Host），源码管理（SVN/Git） ，WEB服务器(nginx,tomcat,Resin)】基础【Http，REST，跨域，语法，Websocket,数据库，计算机网络，操作系统，算法，数据结构】框架【Spring，AOP，Quartz，Json TagLib,tiles,activeMQ,memcache,redis,mybatis,log4j,junit等等等等等】业务【金融，教育，医疗，汽车，房产等等等等各种行业】。 六 .DBA  1 工作内容：如果你做了一个DBA，基本上会遇到两种情况。一种是你的后端工程师懂架构，知道怎么合便使用DB，知道如何防止穿透DB，那么恭喜你，你只是需要当一个DB技术兜底的顾问就好，基本上没什么活可以做，做个监控，写个统计就好了。你可以花时间在MongoDB了，Hadoop了这些，随便玩玩儿。再按照我之前说的，做好数据备份。如果需求变动比较大，往往会牵涉到一些线上数据的更改，那么就在发布的时候安静的等着，等着他们出问题。。。。如果不出问题就可以回家睡觉了。 2 需要技能：环境【Linux，Mysql，Oracle，MongoDB，Hadoop】工具【各种DB的版本，工具，备份，日志等】。 七. 运维  1 工作内容：运维的工作大概分成几个部分，我对于修真院学习运维的少年们都这么说，大概是：A。基础环境的搭建和常用软件的安装和配置（兼网管的还有各种程控机）,常用软件指的是SVN，Git，邮箱这种，更细节的内容请参考修真院对于运维职业的介绍。B。日常的发布和维护，如刚刚讲到的一样，测试环境和线上环境的发布和记录，原则上，对线上所有的变更都应该有记录。C。数据的备份和服务的监控&安全配置。各种数据，都要做好备份和回滚的手段，提前准备好各种紧急预案，服务的监制要做好。安全始终都是不怎么被重点考虑的问题，因为这个东西无底洞，你永远不知道做到什么程度算是比较安全了，所以大多数都是看着情况来。D。运维工具的编写。这一点在大的云服务器商里格外常见，大公司也是一样的。E。Hadoop相关的大数据体系架构的运维，确实有公司在用几百台机器做Hadoop，所以虽然不常见，我还是列出来吧。 2 需要技能：环境【Linux，Mysql，Oracle，MongoDB，Hadoop，nginx,apache,F5,lvs,vpn,iptable，svn,git,memcache,redis】工具【linux 常用工具，Mysql常用工具，Jenkins，zabbix,nagios】自动化运维【openstack,docker,ansible】语言【shell,python】 八 .QA  1 工作内容：QA需要了解需求，很多公司会要求QA写测试用例，我觉得是扯淡。完全是在浪费时间。通常开发三周，QA测试的时间只有一周到一周半。还有关于提前写测试用例的，都不靠谱。 2 需要技能：流程【Bug修复流程，版本发布流程】工具【禅道，BugZilla，Jira,Excel表格来统计Bug数，自动化测试】性格【严谨，耐心】 九. 算法工程师  1 工作内容：算法工程师的工作内容，大部分时间都是在调优。就是调各种参数和语料，寻找特征，验证结果，排除噪音。也会和Hadoop神马的打一些交道，mahout神马的，我那个时候还在用JavaML。现在并不知道有没有什么更好用的工具了。有的时候还要自己去标注语料---当然大部分人都不爱做这个事儿，会找漂亮的小编辑去做。2 需要技能：基础【机器学习，数据挖掘】工具【Mahout，JavaML等其他的算法工具集】 十. 搜索工程师  1 工作内容： 所以搜索现在其实分成两种。一种是传统的搜索。包括：A。抓取 B。解析C。去重D。处理E。索引F。查询另一种是做为架构的搜索。并不包括之前的抓取解析去重，只有索引和查询。A。索引B。查询 2 需要技能：环境【Linux】框架【Luence,Slor,ElasticSearch,Cassandra,MongoDB】算法【倒排索引，权重计算公式，去重算法，Facet搜索的原理，高亮算法，实时索引】 十一. 大数据工程师  1 工作内容：工作内容在前期会比较多一些，基础搭建还是一个挺讲究的事儿。系统搭建好之后呢，大概是两种，一种是向大数据部门提交任务，跑一圈给你。一种是持续的文本信息处理中增加新的处理模块，像我之前说的增加个分类啦，实体识别神马的。好吧第一种其实我也不记得是从哪得来的印象了，我是没有见到过的。架构稳定了之后，大数据部门的工作并不太多，常常会和算法工程师混到一起来。其他的应该就是大数据周边产品的开发工作了。再去解决一些Bug什么的。2 需要技能：环境【Linux】框架【Hadoo,spark,storm,pig,hive,mahout,zookeeper 】算法【mapreduce,hdfs,zookeeper】。 十二. Android工程师  1 工作内容：Android工程师的日常就是听产品经理讲需求，跟后端定接口，听QA反馈哪款机器不兼容，闹着申请各种测试机，以及悲催的用Android做IOS的控件。 2 需要技能：环境【Android Studio，Maven,Gradle】基础【数据结构，Java，计算机网络】组件【IM，地图，支付，拍照，视频，音频，统计，分享，手势密码】 十三. IOS工程师  1 工作内容：IOS工程师的工作内容真的挺简单的，听需求，定接口。做个适配，抛弃一下iphone4。还有啥。。马丹，以我为数不多的IOS知识来讲，真的不知道还有啥了。我知道的比较复杂的系统也是各种背景高斯模糊，各种渐变，各种图片滤镜处理，其他并没有什么。支付，地图，统计这些东西。 嗯。2 需要技能：环境【Xcode】基础【数据结构，Object，计算机网络】组件【IM，地图，支付，拍照，视频，音频，统计，分享，手势密码】

面试经历： 一面内容： 1，上来面试官就说，先做道题：f(n)=f(n-1)+f(n-2)+f(n-3) ,n>=3 写一个高效算法求f(n),最后再其指引过程中做了个较好的结果，最好的没想出来 2， 叫我讲述A*算法，因为我游戏里用到了 3, 求 二叉树的最大子树和，没见过的题目，不过居然想出来了，然后面试官对此题目扩展，如果答出最难的，评级就是A+ 4，介绍项目相关，画了个图解释了下就过了 二面内容： 1, 问了一大堆tcp相关的问题，RST在tcp协议中有啥作用，线程进程问题，线程安全之类的，表示不太会 2, 设计一个类，给出了2个函数，要你实现，给你一个结构体数组，结构体如下：struct Node{int id, Data data},输入一个结构体数组，实现2个函数，vector<Node> getAll() 返回这 结构体数组中相同id项的最后一次出现的那个结构体，void add(Node node);添加一个结构体到类的private数据结构里。用hash可以解决 3,如果给o你一个网易游戏的offer和阿里的offer，你选哪个。这问题问的可以。。。。。。 4还问了道算法题，具体忘了，有点难 面内容： 三面时面试官的桌子上写着算法工程师，当时直接吓尿，算法蒟蒻表示压力山大，结果出了2道智力题。。。。。 1, 给你2k+1个连续格子，2人下棋，规则是，当一个人在某个格子下子的时候，该棋子左右2边的格子都会被占掉，也就是说不能在这里下棋了，当一个人下子后这个棋盘没有空余位 置则该人获胜，问这个游戏是否有必胜策略，当时我觉得好难，最后我从1个格子，3个格子，5个格子这样一次找规律，然后面试官提示了对称性，最后居然解决了 2，A ,B,C3人坐在一个圆桌旁，每人帽子上有个数字，每个人都可以看到其他2人的数字，不知道自己的数字，并且都知道这3个数字呈等比数列这一关系。这是第四者问A，你知道你 的数字是啥么。A说不知道，然后问B，B说不知道，然后问C，C说知道了。。。。。。。请问：这时你能推断出什么。 我在纸上列出了可能的情况，但是还是找不到突破口，最 后面试官解释了，我没听懂，太绕了，这题目需要很强的逻辑能力， 3面就这样结束了 四面内容： hr面，各种人生和价值观问题 1，你为什么选择阿里，阿里文化是什么，我说了几个，扯了下马云自传 2，你有女朋友么。当然回答没有，理由：找女朋友这事不要急，你现在要做的只是设法提升自己，不断让自己更强，等到时机成熟，就不是你去找别人了，而是别人来找你 3，你有参加过集体活动么。怎么处理人际间的矛盾，怎么为人处事之类的 4，父母是干啥的。这个也问我也是醉了。

综上，各种对比之后，有如下建议： 一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高； 不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？ 【Java问答学堂】10期 es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？ 【Java问答学堂】11期 es 生产集群的部署架构是什么？每个索引的数据量大概有多少？ 【Java问答学堂】12期 项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？ 【Java问答学堂】13期 redis 和 memcached 有什么区别？ 【Java问答学堂】14期 redis 都有哪些数据类型？分别在哪些场景下使用比较合适？ 【Java问答学堂】15期redis 的过期策略都有哪些？内存淘汰机制都有哪些？ 【Java问答学堂】16期如何保证 redis 的高并发和高可用？redis 的主从复制原理能介绍 为什么使用消息队列？【Java问答学堂】17期 消息队列有什么优点和缺点？【Java问答学堂】18期

在这个信息时代高速发展的情况下，很多人会对自己该往哪个方向发展感到迷茫，下面我就浅显的给大家介绍一下五大流行区域的发展前景。大数据的发展前景：当前大数据行业真的是人才稀缺吗?学了几年后，大数据行业会不会产能过剩?大数据行业最终需要什么样的人才?接下来就带你们看看分析结果：当前大数据行业真的是人才稀缺吗?对!未来人才缺口150万，数据分析人才最稀缺。先看大数据人才缺口有多大?根据LinkedIn(领英)发布的《2016年中国互联网最热职位人才报告》显示，研发工程师、产品经理、人力资源、市场营销、运营和数据分析是当下中国互联网行业需求最旺盛的六类人才职位。其中数据分析人才最为稀缺、供给指数最低。同时，数据分析人才跳槽速度也最快，平均跳槽速度为19.8个月。而清华大学计算机系教授武永卫去年透露了一组数据：未来3-5年，中国需要180万数据人才，但目前只有约30万人。大数据行业未来会产能过剩吗?提供大数据技术与应用服务的第三方公司面临调整，未来发展会趋集中关于“大数据概念是否被过度炒作”的讨论，其实2013年的夏季达沃斯就有过。彼时支持“炒作”观点的现场观众达54.5%。对此，持反对意见的北京大学光华管理学院副教授苏萌提出了三个理由：不同机构间的数据还未真正流动起来，目前还只是数据“孤岛”;完整的生态产业链还未形成，尽管通过行为数据分析已能够分辨出一个消费者的喜好，但从供应到购买的链条还没建成;数据分析人才仍然极度匮乏。4年之后，舆论热点已经逐渐从大数据转向人工智能，大数据行业也历经整合。近一年间，一些大数据公司相继出现裁员、业务大调整等情况，部分公司出现亏损。那都是什么公司面临危机呢?基于数据归属，涉及大数据业务的公司其实有两类：一类是自身拥有数据的甲方公司，如亚马逊、阿里巴巴等;另一类是整合数据资源，提供大数据技术与应用服务的第三方公司。目前行业整合出现盈利问题的公司多集中在第三方服务商。对此，LinkedIn(领英)中国技术副总裁王迪表示，第三方服务商提供的更多的是技术或平台，大数据更多还是让甲方公司获益。在王迪看来，大数据业务要产生规模效益，至少要具备三点：算法、计算平台以及数据本身。“第三方大数据创业公司在算法上有一技之长，而计算能力实际上已经匀化了，传统企业如果用好了，和大数据创业公司没有区别，甚至计算能力更强，而数据获取方面，很多数据在传统行业内部并没有共享出来，第三方大数据公司获取这些数据是比较困难的，最后可能谁有数据，谁产生的价值更高。”说白了，数据为王。在2013年，拿到千万级A轮融资的大数据企业不足10家，到2015年，拿到千万级以上A轮融资的企业已经超过30家。直到2016年互联网资本寒冬，大数据行业投资热度有所减退，大数据行业是否也存在产能过剩?王迪认为，目前的行业整合属于正常现象，“经过市场的优胜劣汰，第三方服务领域会出现一些做得比较好的公司，其他公司可能被淘汰或转型做一些垂直行业应用。从社会来看，总的需求量一定是增加的，而对于供给侧，经过行业自然的洗牌，最终会集中在几家优秀的行业公司。”需要什么样的大数据人才?今年3月份，教育部公布了第二批获准开设“数据科学与大数据技术”的高校名单，加上第一批获批的北京大学、对外经济贸易大学、中南大学，一共35所高校获批该专业。今年开始，部分院校将招收第一届大数据专业本科生。大数据人才培养涉及到两方面问题：交叉性学科的人才培养方案是否与市场需求相匹配;学科建设的周期与行业快速更新之间的差距怎样弥合。对于第一个问题，“电商热”时期开设的电子商务专业是一个可吸取经验的样本。2000年，教育部高教司批准了第一批高校开设电子商务本科专业。作为一个复合型专业，电子商务的本科教学涵盖了管理、技术、营销三方面的课程。电子商务领域人才需求量大，但企业却无法从电子商务专业中找到合适的人才，原因何在?职业规划专家姜萌认为，并不是某一个专业对应一个行业热点，而是一个专业集群对应一个行业热点。“比如电子商务专业，我们到电子商务公司里会发现，不是学电子商务的人在做这些工作，而是每个专业各司其职，比如计算机、设计、物流管理、营销、广告、金融等等。现在行业的复合型工作都是由一个专业集群来完成的，而不是一个人来复合一堆专业特点。”大数据专业的人才培养也同样走复合型路线，复旦大学大数据学院的招生简章显示，学院本科人才培养以统计学、计算机科学和数学为三大基础支撑性学科，以生物学、医学、环境科学、经济学、社会学、管理学等为应用拓展性学科，具备典型的交叉学科特征。LinkedIn(领英)中国技术副总裁王迪指出，“从企业应用的角度来看，大数据行业里从事相关职能的同学背景是各异的，大数据作为一个人才培养方向还在探索中，在这个阶段，高校尝试开设硕士课程是很好的实践，但开设一类的本科专业还为时过早。”另一方面，专业人才培养的周期较长，而行业热点不断更新轮替，中间产生的时间差使得新兴专业的志愿填报具备了一定风险。王迪认为，“从今天的产业实践上看，大数据领域依然是从现有专业中挑选人才，教育和市场发展总是有一定差距的，学生本科四年，加上硕士阶段已经是七年之后的事情了，产业已经演进了很多，而教学大纲并不会跟进得那么快。”因此，尽管大数据的应用前景毋庸置疑，但在人才培养层面，复合型人才培养方案会不会重走电子商务专业的老路?学校教育如何赶上行业发展速度?这些都是值得进一步商榷的问题。面对热门专业，志愿填报需要注意啥?了解了大数据行业、公司和大数据专业后，姜萌对于考生填报像大数据相关的热门专业，提出了几条建议：报考热的专业和就业热的专业并不一定是重合的，比如软件、计算机、金融，这些专业的就业率实际并没有那么高，地质勘探、石油、遥感等专业，虽然报考上是冷门，但行业需求大，就业率更高。选择热门专业，更需要考虑就业质量。专业就业好，是统计学意义，指的是平均收入水平高，比如金融专业的收入，比其他纯文科专业的平均收入较高，但落实到个体层面，就业情况就不一样了，尤其像金融专业是典型的名校高学历好就业，但对于考试成绩较低的同学来说，如果去一些普通院校、专科院校学习金融，最后就业情况可能还不如会计专业。志愿填报，除了专业，城市因素也很重要：如果想从事金融、互联网的工作，更适合去一线城市，如果是去三、四线城市的学生可以考虑应用面比较广的专业，就是各行各业都能用到的专业，比如会计专业，专科层次的会计和985层次的会计都有就业渠道。如果先选择报考城市，也可以针对所在城市的行业特点选择专业，比如沿海城市外贸相对发达，选择国际贸易、外语类专业就业情况更好，比如武汉有光谷，选择光电类专业更好就业。最终家长和考生更需要考虑个人与专业匹配的问题，金融、计算机等热门专业不是所有人都适合学，好专业不见得对所有个体都是好的。java的发展前景：由于Java的诸多优点，Java的发展前景十分广泛。比如，在我们中国的市场，Java无论在企业级应用，还是在面向大众的服务方面都取得了不少进展，在中国的电信、金融等关键性业务中发挥着举足轻重的作用。由于SUN、TBM、Oracle等国际厂商相继推出各种基于Java技术的应用服务器以及各种应用软件，推动了Java在金融、电信、制造等领域日益广泛的应用，如清华大学计算机系利用Java、XML和Web技术研制开发了多个软件平台，东方科技的TongWeb、中创的Inforweb等J2EE应用服务器。由此可见，在巨大市场需求下，企业对于Java人才的渴求已经是不争的事实。你问我火了这么多年的Java语言的发展前景怎么样？那来看看吧Java在WEB、移动设备以及云计算方面前景广阔，随着云计算以及移动领域的扩张，更多的企业在考虑将其应用部署在Java平台上。无论是本地主机，公共云，Java都是目前最适合的选择。;另外在Oracle的技术投资担保下，Java也是企业在云应用方面回避微软平台、在移动应用方面回避苹果公司的一个最佳选择。Java可以参与制作大部分网络应用程序系统，而且与如今流行的WWW浏览器结合很好，这一优点将促进Java的更大范围的推广。因为在未来的社会，信息将会传送的更加快速，这将推动程序向WEB程序方向发展，由于Java具有编写WEB程序的能力，并且Java与浏览器结合良好，这将使得Java前景充满光明的发展。Python的发展前景：Python程序员的发展前景是怎样的？随着Python的技术的流行， Python在为人们带来工作与生活上的便捷后，关注者们开始慢慢关心Python的发展前景与方向。从自身特性看Python发展Python自身强大的优势决定其不可限量的发展前景。Python作为一种通用语言，几乎可以用在任何领域和场合，角色几乎是无限的。Python具有简单、易学、免费、开源、可移植、可扩展、可嵌入、面向对象等优点，它的面向对象甚至比java和C#、.net更彻底。它是一种很灵活的语言，能帮你轻松完成编程工作。强大的类库支持，使编写文件处理、正则表达式，网络连接等程序变得相当容易。能运行在多种计算机平台和操作系统中，如各位unix，windows，MacOS,OS/2等等，并可作为一种原型开发语言，加快大型程序的开发速度。从企业应用来看Python发展Python被广泛的用在Web开发、运维自动化、测试自动化、数据挖掘等多个行业和领域。一项专业调查显示，75%的受访者将Python视为他们的主要开发语言，反之，其他25%受访者则将其视为辅助开发语言。将Python作为主要开发语言的开发者数量逐年递增，这表明Python正在成为越来越多开发者的开发语言选择。目前，国内不少大企业都已经使用Python如豆瓣、搜狐、金山、腾讯、盛大、网易、百度、阿里、淘宝、热酷、土豆、新浪、果壳等;国外的谷歌、NASA、YouTube、Facebook、工业光魔、红帽等都在应用Python完成各种各样的任务。从市场需求与薪资看Python发展Python得到越来越多公司的青睐，使得Python人才需求逐年增加，从市场整体需求来看，Python在招聘市场上的流行程度也是在逐步上升的，工资水平也是水涨船高。据统计Python平均薪资水平在12K，随着经验的提升，薪资也是逐年增长。学习Python的程序员，除去Python开发工程师、Python高级工程师、Python自动化测试外，也能够朝着Python游戏开发工程师、SEO工程师、Linux运维工程师等方向发展，发展方向较为多元化。随着Python的流行，带动的是它的普及以及市场需求量，所以现在学习Python是个不错的时机。区块链的发展前景：区块链开发 ? 155---0116---2665 ?可是区块链技术到底是什么，大多数人都是模糊没有概念。通俗来讲，如果我们把数据库假设成一本账本，读写数据库就可以看做一种记账的行为，区块链技术的原理就是在一段时间内找出记账最快最好的人，由这个人来记账，然后将账本的这一页信息发给整个系统里的其他所有人。区块链技术也称分布式账本（或账簿）技术，属于互联网数据库技术，由参与者共同完成数据库记录，特点是去中心化和公开透明。此外，在每个区块的信息写入并获得认可后，整个区块链数据库完整保存在互联网的节点中，难以被修改，因此数据库的安全性极高。人们普遍认为，区块链技术是实现数字产品（如货币和知识产权）快速、安全和透明地对等（P2P）转账或转让的重要手段。在以色列Zen Protocol公司，区块链应用软件开发专家阿希尔·曼宁介绍说，他们公司正在开发Zen区块链平台，其将用于支持金融产品在无中介的环境下自动和自由交易。通常，人们将钱存放在银行，依靠银行管理自己的资金。但是，在支配资金时往往会受到银行规定的限制，或在汇款时存在耗时长、费用高等问题。区块链技术平台将让人们首次拥有自己管理和支配钱财的能力，他相信去中心化金融管理体系具有广阔的市场，有望极大地改变传统的金融市场。2018年伊始这一轮区块链的热潮，主要起源于虚拟货币的炒作热情。站在风口，区块链技术被认为是继蒸汽机、电力、互联网之后，下一代颠覆性的核心技术。很多人不禁要问“区块链又和比特币又是什么关系？”记者查询了大量资料发现，比特币2009年被一位名叫中本聪的人提出，之后比特币这套去中心化的机制一直稳定运行，这引起很多人对这套历史上并不存在的运行机制强烈关注。于是人们把从比特币技术抽象提取出来的技术运用于其他领域，称之为区块链。这过程就好像人们先发明了面条，然后人们发现其背后面粉不仅可以做面条还可以做馒头、面包。比特币是面条，区块链是面粉。也就是说，区块链和比特币的关系即比特币算是区块链技术的一种应用，或者说一种使用了区块链技术的产品形态。而说到区块链不得不说的就是ICO，它是一种公开发行的初始数字货币。对于投资人来说，出于对市场信号的敏感和长期关注价值投资项目，目前炙手可热的区块链也成为诸多投资人关注的新兴项目之一。“区块链对于我们来说就是省去了中间环节，节约了交易成本，节省了交易时间，但是目前来看各方面环境还不够成熟，有待观望。”一位投资人这样说道。记者发现，在春节期间，不少互金圈的朋友熬夜到凌晨进入某个探讨区块链的微信群热聊，此群还吸引了不少知名人士，诸如明星加入，同时还有大咖在群里解读区块链的投资方式和未来发展等等。一时间，关于区块链的讨论群接二连三出现，也引发了各个行业对区块链的关注。出于对于区块链技术懵懂的状态，记者追问了身边的一些互金圈的朋友，为何如此痴迷区块链？多数朋友认为“区块链能赚钱，抱着试试看的心态，或许能像之前比特币一样从中获取收益。”显然，区块链技术具有广阔的应用潜力，但是在其逐步进入社会改善民众生活的过程中，也面临许多的问题，需要积极去寻求相应的对策，最终让其发挥出潜力。只有这样，10年或20年后人们才能真正享受区块链技术创造的美好环境。人工智能的发展前景：人工智能产业是智能产业发展的核心，是其他智能科技产品发展的基础，国内外的高科技公司以及风险投资机构纷纷布局人工智能产业链。科技部部长万钢3月10日表示，加快实施新一代人工智能科学基础的关键技术系统集成研发，使那些研发成果尽快能够进入到开放平台，在开放使用中再一次把它增强完善。万钢称，马上就要发布人工智能项目指南和细则，来突破基础前沿理论关键部分的技术。人工智能发展趋势据前瞻产业研究院《人工智能行业市场前瞻与投资战略规划分析报告》指出，2017年中国人工智能核心产业规模超过700亿元，随着国家规划的出台，各地人工智能相关建设将逐步启动，预计到2020年，中国人工智能核心产业规模将超过1600亿元，增长率达到26.2%。报告认为，从产业投资回报率分析，智能安防、智能驾驶等领域的快速发展都将刺激计算机视觉分析类产品的需求，使得计算机视觉领域具备投资价值；而随着中国软件集成水平和人们生活水平的提高，提供教育、医疗、娱乐等专业化服务的服务机器人和智能无人设备具备投资价值。人工智能现状当前，人工智能受到的关注度持续提升，大量的社会资本和智力、数据资源的汇集驱动人工智能技术研究不断向前推进。从发展层次来看，人工智能技术可分为计算智能、感知智能和认知智能。当前，计算智能和感知智能的关键技术已经取得较大突破，弱人工智能应用条件基本成熟。但是，认知智能的算法尚未突破，前景仍不明朗。今年，随着智力资源的不断汇集，人工智能核心技术的研究重点可能将从深度学习转为认知计算，即推动弱人工智能向强人工智能不断迈进。一方面，在人工智能核心技术方面，在百度等大型科技公司和北京大学、清华大学等重点院校的共同推动下，以实现强人工智能为目标的类脑智能有望率先突破。另一方面，在人工智能支撑技术方面，量子计算、类脑芯片等核心技术正处在从科学实验向产业化应用的转变期，以数据资源汇集为主要方向的物联网技术将更加成熟，这些技术的突破都将有力推动人工智能核心技术的不断演进。工业大数据2022 年我国工业大数据有望突破 1200 亿元， 复合增速 42%。 工业大数据是提升制造智能化水平，推动中国制造业转型升级的关键动力，具体包括企业信息化数据、工业物联网数据，以及外部跨界数据。其中，企业信息化和工业物联网中机器产生的海量时序数据是工业数据的主要来源。工业大数据不仅可以优化现有业务，实现提质增效，而且还有望推动企业业务定位和盈利模式发生重大改变，向个性化定制、智能化生产、网络化协同、服务化延伸等智能化场景转型。预计到 2022 年，中国工业大数据市场规模有望突破 1200亿元，年复合增速 42%。IT的未来是人工智能这是一个指数级增长的时代。过去几十年，信息技术的进步相当程度上归功于芯片上晶体管数目的指数级增加，及由此带来的计算力的极大提升。这就是所谓的摩尔定律。在互联网时代，互联的终端数也是超线性的增长，而网络的效力大致与联网终端数的平方成正比。今天，大数据时代产生的数据正在呈指数级增加。在指数级增长的时代，我们可能会高估技术的短期效应，而低估技术的长期效应。历史的经验告诉我们，技术的影响力可能会远远的超过我们的想象。未来的计算能力人工智能需要强大的计算能力。计算机的性能过去30年提高了一百万倍。随着摩尔定律逐渐趋于物理极限，未来几年，我们期待一些新的技术突破。先谈一下类脑计算。传统计算机系统，长于逻辑运算，不擅长模式识别与形象思维。构建模仿人脑的类脑计算机芯片，我们今天可以以极低的功耗，模拟100万个神经元，2亿5千万个神经突触。未来几年，我们会看到类脑计算机的进一步的发展与应用随着互联网的普及、传感器的泛在、大数据的涌现、电子商务的发展、信息社区的兴起，数据和知识在人类社会、物理空间和信息空间之间交叉融合、相互作用，人工智能发展所处信息环境和数据基础发展了巨大的变化。伴随着科学基础和实现载体取得新的突破，类脑计算、深度学习、强化学习等一系列的技术萌芽预示着内在动力的成长，人工智能的发展已进入一个新的阶段。发展发展前景好，代表你现在学习会比后来者起步快，占有更大的优势，当然，你也要明白兴趣是最好的老师，选择自己感兴趣的相信你学的会更加而牢固。记住，最重要的一点：方向最重要！！！希望大家多多关注. ，加微信zhanglindashuju 可以获取更多资料哦作者：失色的瞳孔链接：https://juejin.im/post/5b1a6531e51d45067e6fc24a来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Re吐槽一下阿里云的slb 引用第2楼vpsmm于2013-04-27 12:01发表的  : 这个东西到底能不能支持商业运营？ 未知，我配置过最大的SLB支持环境，日IP30W，PV150W。DZ的动漫论坛，总带宽在20M（论坛）附件另放到OSS了。 这个东西到底能不能在大访问量下稳定运行？ 同上，我实际用到的最大访问量了。 这个东西到底能不能真正实现均衡的负载？ ....... 知道你是阿里云的铁杆粉丝。但说话要客观！ 麻烦你给出你所谓配置过（并且能正常运行访问）的网站地址、拓扑图以及资源使用情况！ 实际应用是在服务器繁忙的情况下，aliyun的slb不能很好地完成转发，其中原因有可能是cpu、io等多方面造成的。并且经常出现很多莫名其妙的故障，博客园实际上就是一个典型的例子！ 博客园在使用过程中得到很多工程师的帮助，这个你看到了？为很么别人不能得到很多工程师的帮助？这对其他用户公平吗？ ------------------------- Re吐槽一下阿里云的slb 引用第4楼billlee于2013-04-27 12:18发表的  : 首先，需要告诉楼主的是：无论SLB是否是一个已经正式商用的产品，我们对外所能提供的服务质量与已经正式商用的其他产品都是没有区别的。并不会存在非正式商用的产品存在稳定性差或服务标准低的说法。 其次，关于SLB的性能和所能达到的对外服务能力，这个除了SLB系统本身所能支持的范畴有关外，也与SLB后端的ECS云服务器本身性能有着密切的关系。但是，可以确保的是SLB系统本身是以集群的方式工作的，当我们系统还没有达到服务瓶颈的时候我们就会做横向的扩容从而确保系统本身的稳定性和可用性。所以，建议楼主在实际使用前可以根据自己的实际应用场景测试一下相关的服务，从而做到心里有数。 关于问题中涉及到的一些细节，比如SLB的转发、SLB的健康检查回报等问题，我看到@vpsmm已经做了较为详细的解答，也请楼主了解，同时感谢@vpsmm的热心回答。 ....... 非常感谢你的回复。 但我也注意到第二段文字。其中“这个除了SLB系统本身所能支持的范畴有关外，也与SLB后端的ECS云服务器本身性能有着密切的关系。” 实践证明，使用阿里云单机，cup占用较高的时候可能问题不大，但在slb里，ecs单机cpu占用一旦超过60-70%就很容易出问题，具体表现也不太一致。博客园的现象即是如此，我所知道的其他几个中型网站也是如此，只不过人家没说而已。 希望你们认真测试一下。 ------------------------- Re回5楼billz的帖子 引用第7楼vpsmm于2013-04-27 12:31发表的 回 5楼(billz) 的帖子 : 这是我帮朋友做的，网址就不公布了。只是一个十分简单的DZ论坛，没有太过详细的拓扑图。 目前附件是OSS上面，这个就没什么多说的。DZ比较简单，只要涉及PHP程序和MYSQL就行了。 单独一台4核CPU，8G内存，拿来跑MYSQL。 一台标准A，拿来跑uc。 ....... 四台标准B，拿来跑php程序，（全部在SLB里）。 用这个跑日IP30W，PV150W？你这真有点忽悠！ 你要说别的行业我可能还不是很清楚，国内动漫论坛.....哈哈，你算忽悠错了。 ------------------------- Re回6楼billz的帖子 引用第11楼billlee于2013-04-27 13:14发表的 回 6楼(billz) 的帖子 : 如果SLB系统真的像楼主描述的那样存在当后端云服务器出现CPU利用率达到60-70%就会出现SLB访问不稳定的情况，那么我的建议是楼主可以通过工单提供一下你的VIP信息，我们的工作人员会帮助你针对这个情况进行核实和问题定位的。 相信已经有人和你们反映过类似的情况了。 由于这个问题指向并不是非常明确，故障现象也不很统一，所以发工单也未必能解决什么问题。你们自己多做做测试就能发现问题。 更何况发给你们的工单一般都是先由小客服们做第一手处理，这种问题他还没搞明白咋回事随手就被他给被关闭了。解决不了问题还惹一肚子气，没啥用处的。 ------------------------- Re回12楼billz的帖子 引用第13楼billlee于2013-04-27 13:32发表的 回 12楼(billz) 的帖子 : 那楼主是否方便把发生在你身上和你对外提供服务身上的问题直接提交给我，我们首先针对这个问题进行分析呢？这样至少可以先解决楼主自身的疑惑和困扰，从而确保楼主对外的服务问题得到妥善的解决。 另，关于客服工单服务质量的问题，我们内部已经在进一步加强对客服人员的培训和处理流程的优化，相信通过我们的努力一定会提升服务质量和专业度，从而保证所有用户通过工单提交的问题都能得到明确的定位、准确的解答和妥善的解决。 还是先不说了。我们已经被迫将cpu的占用都降到50%以下。 你们还是先好好搞一下你们的产品和服务吧。 看看今天的微博，你们已经被喷的很惨了，这样下去要完蛋的。只听那些小站长们拍马屁是没有用的。 http://weibo.com/1670517015/zu41ne2pY#_rnd1367043576717 ------------------------- Re回14楼billz的帖子 引用第17楼billlee于2013-04-27 15:28发表的 回 14楼(billz) 的帖子 : 既然不稳定的问题已经出现在了你的对外应用服务中，我的建议还是希望你能够配合我们一起把问题查一下，这样对于我们自身系统的成长和你本身对外服务的稳定性来说都是有益的。如果通过定位分析，问题真的是由SLB系统造成的，那么我们肯定会尽快给予解决和修复。因为很多问题在没有复现和最终定位的情况下只是通过简单的通用性测试是没有办法涵盖所有case和应用场景的（随着客户的逐渐增加，客户本身的应用场景越来越复杂和个性化，我们也需要大家的帮助来不断的完善我们的平台和服务），所以还是希望你能够协助我们一并解决问题，而不是采取变相的手段来掩盖问题本身。 阿里云的成长需要大家一起的努力来达成，感谢你及其他用户的支持！ 你作为官方人士，在于用户交流的时候应该注意言辞。 作为用户，我没有必要替你们“掩盖”问题，我们只是以最简洁、高效的方式去处理问题。这里的用户提出过很多很多有益的建议，你们都能够迅速的处理解决吗？明显是不能的。所以，不如我们自己先改变一下部署，以便能够正常运营。 问题本身的解决还是依靠你们自己吧。看看几天微博的吐槽，人家说的一些问题都是事实吧，其中有些我们也经历过。论坛里大部分都是开小网站的，他们也许不会很在意停机几分钟甚至几小时，但这对一个中型网站，每一分钟的停顿都会造成直接的经济损失的网站来说意味着什么你们应该不难能理解吧？ cpu、io性能问题、用户间相互印象的问题等等等等，拜托你们多下点功夫吧。 ------------------------- Re吐槽一下阿里云的slb 引用第32楼twl007于2013-04-28 00:16发表的  : 这帖子都喷成这样了 - - 我自己的使用经验来看 SLB的稳定性是跟RDS有的一拼的 用了一年多的SLB真正因为SLB自身原因引起的故障寥寥无几 大部分情况是服务器超载了SLB返回503 印象中没有因为SLB自身故障导致网站挂掉的 个人觉得SLB更侧重于提升网站的可用性 提升负载能力倒是次要了 当你网站需要多台服务器进行热备的时候SLB的重要性不言而喻 至于多台机器提升性能 我自己是用来看很少从性能方面考虑SLB 如果你真的需要两台一起工作才能承载整个网站访问 那么一台down掉 另一台也会因为承受不住压力down掉 这种情况下部署SLB是无意义的 只有在确定单台能满足要求然后横向扩展时才能发挥SLB提高网站可用性的作用 ....... 作为一个版主对slb的理解居然如此片面 ------------------------- Re回33楼alilab的帖子 引用第38楼twl007于2013-04-28 10:10发表的 回 33楼(alilab) 的帖子 : 难道是人品问题么 - - 我们从一年多前开始用阿里云就在使用SLB了 那时候功能还没现在的完善 但是我用到现在也只遇到过一次因为SLB故障我无法创建修改服务器集群 并没有出现过无法访问的问题…… 用了这么久SLB跟RDS是出问题最少的…… 每次工单问我们都有记录 真正问题原因是SLB引起的真心一次没有…… 而且SLB曾经多次在我们一台挂掉服务器状态的情况下成功把所有访问转移到另一台服务器 保证了网站没中断 ....... 先说说你的系统架构和流量数据。别吹牛b就行。 小站应该是没啥问题的。

Re【马甲问题】马甲账号清除公告 以前某社交公司查mj，就是用登陆浏览器比对。比对下登陆提交的浏览器地址，就全查出来了。 对于文本内容的比对感觉作用不大，我想过和别的组的尝试合并提交，只多出来200个提交。 ------------------------- Re【马甲问题】马甲账号清除公告 不过说句实在话，参加这么多竞赛过来，我还是第一次看到竞赛主办方用查mj的方式来抑制选手调参数过拟合训练数据集的。在最后一周更改测试集才是通用的做法吧。 我个人来说，同一策略线下验证集调好参数后，线上不会改参数超过两次，也是担心太过拟合，第二赛季就傻了。 ------------------------- Re【马甲问题】马甲账号清除公告 恩，看到规则了，话说第一季我觉得这样做可能比较好：训练集不变，然后测试集800个人随机抽样400个人作为平时的leadership排名，最后评测的时候用剩下400个人。这样刷小号也没意义了。 （突然想到回去后要跟我实验室的其他队伍说一声。。。以后LR调好W后别用我那个python脚本生成提交数据了。。。免得被当小号处理了omg ------------------------- 回22楼jiajiadidi的帖子 你不是改个参数几个队一起刷的话应该还好吧 我当初就觉得这样不好，后面多半要出乱子。浙大宣讲问主办方，现在这种情况，几条简单规则就能刷到6，我要是把这几条简单的规则告诉别人，那别人不都挤到前面，那赛季1不就没意义了？然后还有mj的问题。 宣讲的老师说，那你觉得现在极限是多少呢？是7么。mj这种问题都是小问题 后来算者说得好，规则确实能做得比较好，怎么结合规则做出更好的模型才是王道，模型不如规则只能说模型做的不够好。这个对我影响还蛮大的，也让我好好反思了一下。 我现在靠LR做到6.8，基本也没做规则了，而是想如何用以前淘宝有个做CTR预估的MLR的思路结合商品类目和用户定向做更好的结合规则的LR。 我把我python工程环境也发给同实验室的其他组了，在我基础上也有比我做的更高的，具体来说也没太问。 今天回贴，也是看到这种情况有所感想。 大家去刷规则，把推荐大赛做成overfitting大赛，这样对于自己的提高，或是解决这个实际问题，这样有意义么？我是觉得没有意义的。 跟我用同一体系方法的几个队，现在基本都做到6.9 6.8了，大家还是把精力更多放在了如何做更好的模型上。 想想最初学的PAC，一个模型如何叫好，train error低，并且train error近似于test error。这样我们才能声称自己的模型学习到了真正的target function f。而目前大家凭着test 来不断调整参数，就算把f1做到天上去，自己的模型只能说train error低了，大赛后也是毫无意义的。算法学到的那个function，也最多只能当作笑谈 看到有置顶，真是受宠若惊了。帖子里面说的MLR，是盖坤/靖世在阿里技术沙龙中分享的《海量数据下的非线性模型探索 》http://club.alibabatech.org/resource_detail.htm?topicId=106 。这个ppt非常好，我也学到不少。 顺便说说的是，在这个比赛中，我也确实学到不少。 以前我在做项目的时候，基本是对算法非常迷信的，关系好的豆瓣算法组的一个人批我机器学习理解不成熟，太喜欢炫技，我也左耳朵进右耳朵出。最近做某公司的推荐项目，我基本想都不想，就要上time SVD++做baseline，对数据也基本不做太多分析，对业务也是不屑一顾的，非常依赖feature selection算法以及高维非线性模型。 在以前kdd cup或者recsys等比赛中，也是直接上定制化的SVD，把所有数据建模在一个式子里跑SGD草草完事。 做阿里比赛最开始我也是没做太多数据分析，直接上的implicit feedback，sigmoid处理正负反馈，time SVD++以及各种复杂的处理方式。与其说是解决问题，不如是说炫技。当然结果也非常惨，只有4%。 后来才开始认真思考这个比赛的问题。品牌推荐和普通推荐到底有什么区别？打个比方，用户在一个月后会看自己以前有交互的电影的只有1%。而用户在一个月后会买自己以前有交互的品牌的却有20%。CF着力的是那没有交互行为的80%的品牌。除此外800用户，对用户的factor的估计，还是加入temporal dynamic稀释的，又能有多准呢？ 所以除了算者说的那些点外，光就这一点基本就可以判定CF在赛季1的不适合了。 这样的问题，只要好好想想就能想通的，可笑的是我第一二周还在所谓的“巧妙模型”上花费了大量的力气。这个让我反思了很久。 用我室友说我的，便是我太迷信算法了，瞧不起用excel写统计的，也瞧不起做简单数据分析然后跑简单模型的人。 这便是我在比赛中获得的教训，也是我和我同实验室的朋友在回家路上所总结的。 说实在，这个比赛我也没有太多精力参加，赛季二估计也只能每周花1天来做，毕竟实验室项目太多。所以估计最后也拿不到特别好的名次。但我觉得，这次比赛前几周给我带来的教训，便已经让我非常有收获了，至少我现在对于机器学习算法以及业务关系的理解，和比赛前已经有了很大的不同。 我现在是单挑，考虑到赛季2最近也找了一个队友，他貌似有两个小号。我也给他发短信让他回学校后赶快发邮件把这些号注销了并入我的队，毕竟也算占着前500的坑，注销了也让更多的队能进入前500。也希望其他队的朋友也再接再厉，在比赛中真正得到一些领悟和经验。愿大家都能做出更好的推荐，进一步加深对机器学习的理解 ^_^ 顺便给大家讲个竞赛的小段子开心开心=w= “阿里的比赛，有个学弟找我合了下数据，做到38名。他觉得很开心，就跟他导师说了。他导师说，才38名啊，做不到前3名就别参加竞赛丢他脸。听到这事我当时就呵呵了，you can you up，no can no bb。我导师就好多了，他要是知道我在做竞赛而不干活，不管几名肯定把我剁了。”

面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队，leader 交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！ 如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。 面试技巧：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。 异步 再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。 一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。 如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！ 削峰 每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。 但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。 如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。 这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。 消息队列有什么优缺点 优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。 缺点有以下几个： 系统可用性降低 系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，ABCD 四个系统还好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整？MQ 一挂，整套系统崩溃，你不就完了？如何保证消息队列的高可用，可以点击这里查看。 系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。 所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。 综上，各种对比之后，有如下建议： 一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高； 不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。