业务属性出问题什么情况

最好一个表，要不然，会员和其他表的关联会出问题，比如会员买东西，会员发表评论，你总不能把评论表也搞成两个，购买记录也搞成两个表吧？后患无穷######搞个字段用来区分会员类型不就OK了？######一个表   用一个字段区分  线下,线上    你线上也需要注册的？ 也就是说你的表的会员都有  帐号,密码字段    你在加个 初始密码是否使用 的字段就完了 至于你说的初始密码的逻辑 //登录 if(线下){ if(!初始密码是否使用){ 初始密码是否使用 = true; } } ...执行登录 ######回复 @ZhangKevin2 : 判断不只是js判断，服务端也要判断 js是可以绕过的，除了问题就大条了######那我就登录的时候 判断 写个正则，凡是DOWN_开头的 帐户名ID都是线下的，否则就执行普通线上注册的用户登录？ 然后线上普通注册的 在注册的时候我在写个JS 限制不能以DOWN_开头注册就行了？ 那线下的帐户名和初始密码 是用EXCEL直接导入数据库会员表里？###### 引用来自“NikoG”的答案 搞个字段用来区分会员类型不就OK了？ 是啊，这个不就解决了吗？然后在付款的时候判断一下不就得了吗？反正那些行为线下会员优惠点的话，直接判断一下不就得了吗？ ######楼主考虑的复杂了吧，你这个情况就如上面提到的，用一个字段识别一下即可。另外，你最后说的VIP和普通会员，与你现在的情况其实是一个性质的。 就和论坛中有不同的用户组一样，不同的组不同的权限，而且也强烈建议你使用权限来区分各用户组所能进行的操作，这样也有利于你日后的扩展。给你一个参考的基础库结构： ID：int(索引) UserID：nvarchar(用户名) Password：nvarchar(密码) Int：int(boolean，是否完成初始化) Group：int(用户组)(另建用户组表，定义各组的权限) Rebate：int(折扣，也可在用户组中定义折扣率，此处的折扣率可用做针对单个用户的私有权限) ######回复 @psaux : 当然CHAR了，MD5之后固定的位数######password直接用char吧，事先确定了使用的hash加密方式和位数。######因为就一个线下和线上 2种情况，所以我觉得没必要搞个用户组来单独搞权限操作######如果线上会员和线下会员区别很大，建议分开表。只是要区分线上线下而已，可以只用一个字段识别。线下会员首次登录需要改密码使用登录次数字段+判断初始密码是否未更改来实现######回复 @ZhangKevin2 : 使用SQL的Left Join就可以。会员类型（线上线下）放置详细表######THANS，登录次数字段还没用过。。 其实还有一点很麻烦，一般会员，如果想登录块点都是分2个会员表，一个是 帐号和密码会员表用户登录，与之相关联的是会员详细信息表，比如会员的个人资料等等。 如此 如果结合线上线下的话 更纠结。。###### 显然分成两个表比较好 而且分成两个系统开发测试也快。 ###### 显然一个表，会员是一个对象，线上线下只是这个对象的属性。你的需求和苏宁电器的会员很类似，苏宁7000多万会员也分线下pos端申请和线上易购网申请，我们用的是一个表，这里存在一个线上线下同步问题，如果会员量小不用考虑都指向一个表就行。另外我们会根据地理区域分库，也就是水平分割，否则检索太慢。首次登陆改密码这个很多会员都有这样的需求，也可以用属性来区别。另外我说的会员一个表是逻辑上的一个表，由于会员有很多属性，都放一个表会影响性能，可以根据业务类型进行垂直切割。 ###### 引用来自“风飞雪”的答案 显然一个表，会员是一个对象，线上线下只是这个对象的属性。你的需求和苏宁电器的会员很类似，苏宁7000多万会员也分线下pos端申请和线上易购网申请，我们用的是一个表，这里存在一个线上线下同步问题，如果会员量小不用考虑都指向一个表就行。另外我们会根据地理区域分库，也就是水平分割，否则检索太慢。首次登陆改密码这个很多会员都有这样的需求，也可以用属性来区别。另外我说的会员一个表是逻辑上的一个表，由于会员有很多属性，都放一个表会影响性能，可以根据业务类型进行垂直切割。 求详细点。。。  之前做的都是普通会员和VIP会员，ECSHOP二次开发等等，这次虽然项目不大也不难，但我还是想尽力做完善点，关键是我们公司策划烂到家了 天天改需求，线上线下会员肯定会有区别，但以后有多大区别还不晓得。 最烦的是有区别又有联系，如果分2个表 以后还要联表。 有些业务处理也麻烦。但如果放在一个表里，2种会员字段数也不一样，线上可能就5个，线下可能还要身份证什么的因为是发卡一对一发展现实中的会员，而且线下会员安全性要求更高 ###### 引用来自“ZhangKevin2”的答案 引用来自“风飞雪”的答案 显然一个表，会员是一个对象，线上线下只是这个对象的属性。你的需求和苏宁电器的会员很类似，苏宁7000多万会员也分线下pos端申请和线上易购网申请，我们用的是一个表，这里存在一个线上线下同步问题，如果会员量小不用考虑都指向一个表就行。另外我们会根据地理区域分库，也就是水平分割，否则检索太慢。首次登陆改密码这个很多会员都有这样的需求，也可以用属性来区别。另外我说的会员一个表是逻辑上的一个表，由于会员有很多属性，都放一个表会影响性能，可以根据业务类型进行垂直切割。 求详细点。。。  之前做的都是普通会员和VIP会员，ECSHOP二次开发等等，这次虽然项目不大也不难，但我还是想尽力做完善点，关键是我们公司策划烂到家了 天天改需求，线上线下会员肯定会有区别，但以后有多大区别还不晓得。 最烦的是有区别又有联系，如果分2个表 以后还要联表。 有些业务处理也麻烦。但如果放在一个表里，2种会员字段数也不一样，线上可能就5个，线下可能还要身份证什么的因为是发卡一对一发展现实中的会员，而且线下会员安全性要求更高 建议一个，如果按你的思路以后如果手机可以注册，为了区别手机注册的还要建个会员表？如果会员系统提供接口给别的系统用，你还要根据会员号去不同的表里查找？显然这样会给系统开发带来不必要的麻烦，这些一个字段就可以解决。现在存储设备如此便宜，为了减少系统复杂而浪费些空间非常值得。不同注册方法的会员字段不同，没有值得让它空着好了，不要太完美了。我们很多表都冗余了浮点和字符的字段，因为需求总是不断变化，时不时的要增加字段，这种冗余字段的方法带来了很多方便。设计系统和表结构首先一个原则就是尽可能的简单，然后再考虑性能最后考虑空间问题。如果会员有上百万建议切割表，将不常用的字段放在另一张表中。 一些拙见，不足之处还望不吝赐教。

在开始谈我对架构本质的理解之前，先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(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、 分布式系 统、数据结构和算法。

转自：阿里云官网 — 知乎 写好代码，阿里专家沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家，相信同样的方法论可以复制到大部分复杂业务场景。 一文教会你如何写复杂业务代码 了解我的人都知道，我一直在致力于应用架构和代码复杂度的治理。 这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景，如何在架构和代码层面进行应对，是一个新课题。针对该命题，我进行了比较细致的思考和研究。结合实际的业务场景，我沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家。 我相信，同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业务背景，零售通是给线下小店供货的B2B模式，我们希望通过数字化重构传统供应链渠道，提升供应链效率，为新零售助力。阿里在中间是一个平台角色，提供的是Bsbc中的service的功能。 在商品域，运营会操作一个“上架”动作，上架之后，商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一，因此涉及很多的数据校验和关联操作。 针对上架，一个简化的业务流程如下所示： 过程分解 像这么复杂的业务，我想应该没有人会写在一个service方法中吧。一个类解决不了，那就分治吧。 说实话，能想到分而治之的工程师，已经做的不错了，至少比没有分治思维要好很多。我也见过复杂程度相当的业务，连分解都没有，就是一堆方法和类的堆砌。 不过，这里存在一个问题：即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中，类似的分解手段至少有3套以上，有自制的流程引擎，有依赖于数据库配置的流程处理： 本质上来讲，这些辅助手段做的都是一个pipeline的处理流程，没有其它。因此，我建议此处最好保持KISS（Keep It Simple and Stupid），即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。 除非你的应用有极强的流程可视化和编排的诉求，否则我非常不推荐使用流程引擎等工具。第一，它会引入额外的复杂度，特别是那些需要持久化状态的流程引擎；第二，它会割裂代码，导致阅读代码的不顺畅。大胆断言一下，全天下估计80%对流程引擎的使用都是得不偿失的。 回到商品上架的问题，这里问题核心是工具吗？是设计模式带来的代码灵活性吗？显然不是，问题的核心应该是如何分解问题和抽象问题，知道金字塔原理的应该知道，此处，我们可以使用结构化分解将问题解构成一个有层级的金字塔结构： 按照这种分解写的代码，就像一本书，目录和内容清晰明了。以商品上架为例，程序的入口是一个上架命令（OnSaleCommand）, 它由三个阶段（Phase）组成。 @Command public class OnSaleNormalItemCmdExe { @Resource private OnSaleContextInitPhase onSaleContextInitPhase; @Resource private OnSaleDataCheckPhase onSaleDataCheckPhase; @Resource private OnSaleProcessPhase onSaleProcessPhase; @Override public Response execute(OnSaleNormalItemCmd cmd) { OnSaleContext onSaleContext = init(cmd); checkData(onSaleContext); process(onSaleContext); return Response.buildSuccess(); } private OnSaleContext init(OnSaleNormalItemCmd cmd) { return onSaleContextInitPhase.init(cmd); } private void checkData(OnSaleContext onSaleContext) { onSaleDataCheckPhase.check(onSaleContext); } private void process(OnSaleContext onSaleContext) { onSaleProcessPhase.process(onSaleContext); } } 每个Phase又可以拆解成多个步骤（Step），以OnSaleProcessPhase为例，它是由一系列Step组成的： @Phase public class OnSaleProcessPhase { @Resource private PublishOfferStep publishOfferStep; @Resource private BackOfferBindStep backOfferBindStep; //省略其它step public void process(OnSaleContext onSaleContext){ SupplierItem supplierItem = onSaleContext.getSupplierItem(); // 生成OfferGroupNo generateOfferGroupNo(supplierItem); // 发布商品 publishOffer(supplierItem); // 前后端库存绑定 backoffer域 bindBackOfferStock(supplierItem); // 同步库存路由 backoffer域 syncStockRoute(supplierItem); // 设置虚拟商品拓展字段 setVirtualProductExtension(supplierItem); // 发货保障打标 offer域 markSendProtection(supplierItem); // 记录变更内容ChangeDetail recordChangeDetail(supplierItem); // 同步供货价到BackOffer syncSupplyPriceToBackOffer(supplierItem); // 如果是组合商品打标，写扩展信息 setCombineProductExtension(supplierItem); // 去售罄标 removeSellOutTag(offerId); // 发送领域事件 fireDomainEvent(supplierItem); // 关闭关联的待办事项 closeIssues(supplierItem); } } 看到了吗，这就是商品上架这个复杂业务的业务流程。需要流程引擎吗？不需要，需要设计模式支撑吗？也不需要。对于这种业务流程的表达，简单朴素的组合方法模式（Composed Method）是再合适不过的了。 因此，在做过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的阶段（Phase）和步骤（Step）上。 过程分解后的两个问题的确，使用过程分解之后的代码，已经比以前的代码更清晰、更容易维护了。不过，还有两个问题值得我们去关注一下： 1、领域知识被割裂肢解什么叫被肢解？ 因为我们到目前为止做的都是过程化拆解，导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程，知识没有沉淀。相同的业务逻辑会在多个Use Case中被重复实现，导致代码重复度高，即使有复用，最多也就是抽取一个util，代码对业务语义的表达能力很弱，从而影响代码的可读性和可理解性。 2、代码的业务表达能力缺失 试想下，在过程式的代码中，所做的事情无外乎就是取数据--做计算--存数据，在这种情况下，要如何通过代码显性化的表达我们的业务呢？ 说实话，很难做到，因为我们缺失了模型，以及模型之间的关系。脱离模型的业务表达，是缺少韵律和灵魂的。 举个例子，在上架过程中，有一个校验是检查库存的，其中对于组合品（CombineBackOffer）其库存的处理会和普通品不一样。原来的代码是这么写的： boolean isCombineProduct = supplierItem.getSign().isCombProductQuote(); // supplier.usc warehouse needn't check if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) { // quote warehosue check if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！"); } // inventory amount check Long sellableAmount = 0L; if (!isCombineProduct) { sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList()); } else { //组套商品 OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId()); if (backOffer != null) { sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale(); } } if (sellableAmount < 1) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + supplierItem.getId() + "]"); } } 然而，如果我们在系统中引入领域模型之后，其代码会简化为如下： if(backOffer.isCloudWarehouse()){ return; } if (backOffer.isNonInWarehouse()){ throw new BizException("亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！"); } if (backOffer.getStockAmount() < 1){ throw new BizException("亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]"); } 有没有发现，使用模型的表达要清晰易懂很多，而且也不需要做关于组合品的判断了，因为我们在系统中引入了更加贴近现实的对象模型（CombineBackOffer继承BackOffer），通过对象的多态可以消除我们代码中的大部分的if-else。 过程分解+对象模型 通过上面的案例，我们可以看到有过程分解要好于没有分解，过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case，如果采用过程分解+对象模型的方式，最终我们会得到一个如下的系统结构： 写复杂业务的方法论 通过上面案例的讲解，我想说，我已经交代了复杂业务代码要怎么写：即自上而下的结构化分解+自下而上的面向对象分析。 接下来，让我们把上面的案例进行进一步的提炼，形成一个可落地的方法论，从而可以泛化到更多的复杂业务场景。 上下结合 所谓上下结合，是指我们要结合自上而下的过程分解和自下而上的对象建模，螺旋式的构建我们的应用系统。这是一个动态的过程，两个步骤可以交替进行、也可以同时进行。这两个步骤是相辅相成的，上面的分析可以帮助我们更好的理清模型之间的关系，而下面的模型表达可以提升我们代码的复用度和业务语义表达能力。其过程如下图所示： 使用这种上下结合的方式，我们就有可能在面对任何复杂的业务场景，都能写出干净整洁、易维护的代码。 能力下沉 一般来说实践DDD有两个过程： 1. 套概念阶段 了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bonded Context，Repository等等这些概念。更进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。 2. 融会贯通阶段 术语已经不再重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。 大体上而言，我大概是在1.7的阶段，因为有一个问题一直在困扰我，就是哪些能力应该放在Domain层，是不是按照传统的做法，将所有的业务都收拢到Domain上，这样做合理吗？说实话，这个问题我一直没有想清楚。 因为在现实业务中，很多的功能都是用例特有的（Use case specific）的，如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反，这种收拢会导致Domain层的膨胀过厚，不够纯粹，反而会影响复用性和表达能力。 鉴于此，我最近的思考是我们应该采用能力下沉的策略。 所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制要求把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了。 注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程 通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。 下沉的过程如下图所示，假设两个use case中，我们发现uc1的step3和uc2的step1有类似的功能，我们就可以考虑让其下沉到Domain层，从而增加代码的复用性。 指导下沉有两个关键指标：代码的复用性和内聚性。 复用性是告诉我们When（什么时候该下沉了），即有重复代码的时候。 内聚性是告诉我们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另一个是Domain的Model这个是最细粒度的复用）。 比如，在我们的商品域，经常需要判断一个商品是不是最小单位，是不是中包商品。像这种能力就非常有必要直接挂载在Model上。 public class CSPU { private String code; private String baseCode; //省略其它属性 /** * 单品是否为最小单位。 * */ public boolean isMinimumUnit(){ return StringUtils.equals(code, baseCode); } /** * 针对中包的特殊处理 * */ public boolean isMidPackage(){ return StringUtils.equals(code, midPackageCode); } } 之前，因为老系统中没有领域模型，没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的，至少我在第一眼看到这个代码的时候，是完全不知道什么意思。 业务技术要怎么做 写到这里，我想顺便回答一下很多业务技术同学的困惑，也是我之前的困惑：即业务技术到底是在做业务，还是做技术？业务技术的技术性体现在哪里？ 通过上面的案例，我们可以看到业务所面临的复杂性并不亚于底层技术，要想写好业务代码也不是一件容易的事情。 业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如，如果你需要去开发Pandora，你就要对Classloader有更加深入的了解才行。 但是，不管是业务技术还是底层技术人员，有一些思维和能力都是共通的。比如，分解问题的能力，抽象思维，结构化思维等等。 用我的话说就是：“做不好业务开发的，也做不好技术底层开发，反之亦然。业务开发一点都不简单，只是我们很多人把它做“简单”了因此，如果从变化的角度来看，业务技术的难度一点不逊色于底层技术，其面临的挑战甚至更大。 因此，我想对广大的从事业务技术开发的同学说：沉下心来，夯实自己的基础技术能力、OO能力、建模能力... 不断提升抽象思维、结构化思维、思辨思维... 持续学习精进，写好代码。我们可以在业务技术岗做的很”技术“！。

　　开发者们都知道在高端智能手机系统中有两种应用程序：一种是基于本地（操作系统）运行的APP；一种是基于高端机的浏览器运行的WebApp，本文将主要讲解后者。 　　WebApp与Native App有何区别呢？ 　　Native App： 　　1、开发成本非常大。 　　一般使用的开发语言为JAVA、C++、Objective-C。 　　2、更新体验较差、同时也比较麻烦 　　每一次发布新的版本，都需要做版本打包，且需要用户手动更新（有些应用程序即使不需要用户手动更新，但是也需要有一个恶心的提示）。 　　3、非常酷 　　因为native app可以调用IOS中的UI控件以UI方法，它可以实现WebApp无法实现的一些非常酷的交互效果 　　4、Native app是被Apple认可的 　　Native app可以被Apple认可为一款可信任的独立软件，可以放在Apple Stroe出售，但是Web app却不行。 　　Web App： 　　1、开发成本较低 　　使用web开发技术就可以轻松的完成web app的开发 　　2、升级较简单 　　升级不需要通知用户，在服务端更新文件即可，用户完全没有感觉 　　3、维护比较轻松 　　和一般的web一样，维护比较简单，它其实就是一个站点 　　Webapp说白了就是一个针对Iphone、Android优化后的web站点，它使用的技术无非就是HTML或HTML5、CSS3、JavaScript，服务端技术JAVA、PHP、ASP。 　　当然，因为这些高端智能手机（Iphone、Android）的内置浏览器都是基于webkit内核的，所以在开发WEBAPP时，多数都是使用HTML5和CSS3技术做UI布局。当使用HTML5和CSS3l做UI时，若还是遵循着一般web开发中使用HTML4和CSS2那样的开发方式的话，这也就失去了WEBAPP的本质意义了，且有些效果也无法实现的，所以在此又回到了我们的主题–webapp的布局方式和技术。 　　哥在此说明一下，在此所说的移动平台前端开发是指针对高端智能手机（如Iphone、Android）做站点适配也就是WebApp，并非是针对普通手机开发Wap 2.0，所以在阅读本篇文章以前，你需要对webkit内核的浏览器有一定的了解，你需要对HTML5和CSS3有一定的了解。如果你已经对此有所了解，那现在就开始往下阅读吧…… 　　1、首先我们来看看webkit内核中的一些私有的meta标签，这些meta标签在开发webapp时起到非常重要的作用 　　1 　　<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" name="viewport" /> 　　2 　　<meta content="yes" name="apple-mobile-web-app-capable" /> 　　3 　　<meta content="black" name="apple-mobile-web-app-status-bar-style" /> 　　4 　　<meta content="telephone=no" name="format-detection" /> 　　 　　第一个meta标签表示：强制让文档的宽度与设备的宽度保持1:1，并且文档最大的宽度比例是1.0，且不允许用户点击屏幕放大浏览； 　　第二个meta标签是iphone设备中的safari私有meta标签，它表示：允许全屏模式浏览； 　　第三个meta标签也是iphone的私有标签，它指定的iphone中safari顶端的状态条的样式； 　　第四个meta标签表示：告诉设备忽略将页面中的数字识别为电话号码 　　2、HTML5标签的使用 　　在开始编写webapp时，哥建议前端工程师使用HTML5，而放弃HTML4，因为HTML5可以实现一些HTML4中无法实现的丰富的WEB应用程序的体验，可以减少开发者很多的工作量，当然了你决定使用HTML5前，一定要对此非常熟悉，要知道HTML5的新标签的作用。比如定义一块内容或文章区域可使用section标签，定义导航条或选项卡可以直接使用nav标签等等。 　　3、放弃CSS float属性 　　在项目开发过程中可以会遇到内容排列排列显示的布局(见下图)，假如你遇见这样的视觉稿，哥建议你放弃float，可以直接使用display:block; 　　4、利用CSS3边框背景属性 　　这个按钮有圆角效果，有内发光效果还有高光效果，这样的按钮使用CSS3写是无法写出来的，当然圆角可以使用CSS3来写，但高光和内发光却无法使用CSS3编写， 　　这个时候你不妨使用-webkit-border-image来定义这个按钮的样式。 　　-webkit-border-image就个很复杂的样式属性。 　　5、块级化a标签 　　请保证将每条数据都放在一个a标签中，为何这样做？因为在触控手机上，为提升用户体验，尽可能的保证用户的可点击区域较大。 　　6、自适应布局模式 　　在编写CSS时，我不建议前端工程师把容器（不管是外层容器还是内层）的宽度定死。为达到适配各种手持设备，我建议前端工程师使用自适应布局模式（支付宝采用了自适应布局模式），因为这样做可以让你的页面在ipad、itouch、ipod、iphone、android、web safarik、chrome都能够正常的显示，你无需再次考虑设备的分辨率。 　　 　　7、学会使用webkit-box 　　上一节，我们说过自适应布局模式，有些同学可能会问：如何在移动设备上做到完全自适应呢？很感谢webkit为display属性提供了一个webkit-box的值，它可以帮助前端工程师做到盒子模型灵活控制。 　　8、如何去除Android平台中对邮箱地址的识别 　　看过iOS webapp API的同学都知道iOS提供了一个meta标签:用于禁用iOS对页面中电话号码的自动识别。在iOS中是不自动识别邮件地址的，但在Android平台，它会自动检测邮件地址，当用户touch到这个邮件地址时，Android会弹出一个框提示用户发送邮件，如果你不想Android自动识别页面中的邮件地址，你不妨加上这样一句meta标签在head中 　　1 　　<meta content="email=no" name="format-detection" /> 　　 　　9、如何去除iOS和Android中的输入URL的控件条 　　你的老板或者PD或者交互设计师可能会要求你：能否让我们的webapp更加像nativeapp，我不想让用户看见那个输入url的控件条？ 　　答案是可以做到的。我们可以利用一句简单的javascript代码来实现这个效果 　　1 　　setTimeout(scrollTo,0,0,0); 　　 　　请注意，这句代码必须放在window.onload里才能够正常的工作，而且你的当前文档的内容高度必须是高于窗口的高度时，这句代码才能有效的执行。 　　10、如何禁止用户旋转设备 　　我曾经也想禁止用户旋转设备，也想实现像某些客户端那样：只能在肖像模式或景观模式下才能正常运行。但现在我可以很负责任的告诉你：别想了!在移动版的webkit中做不到！ 　　至少Apple webapp API已经说到了：我们为了让用户在safari中正常的浏览网页，我们必须保证用户的设备处于任何一个方位时，safari都能够正常的显示网页内容（也就是自适应），所以我们禁止开发者阻止浏览器的orientationchange事件，看来苹果公司的出发点是正确的，苹果确实不是一般的苹果。 　　iOS已经禁止开发者阻止orientationchange事件，那Android呢？对不起，我没有找到任何资料说Android禁止开发者阻止浏览器orientationchange事件，但是在Android平台，确实也是阻止不了的。 　　11、如何检测用户是通过主屏启动你的webapp 　　看过Apple webapp API的同学都知道iOS为safari提供了一个将当前页面添加主屏的功能，按下iphoneipodipod touch底部工具中的小加号，或者ipad顶部左侧的小加号，就可以将当前的页面添加到设备的主屏，在设备的主屏会自动增加一个当前页面的启动图标，点击该启动图标就可以快速、便捷的启动你的webapp。从主屏启动的webapp和浏览器访问你的webapp最大的区别是它清除了浏览器上方和下方的工具条，这样你的webapp就更加像是nativeapp了，还有一个区别是window对像中的navigator子对象的一个standalone属性。iOS中浏览器直接访问站点时，navigator.standalone为false,从主屏启动webapp时，navigator.standalone为true， 我们可以通过navigator.standalone这个属性获知用户当前是否是从主屏访问我们的webapp的。 　　在Android中从来没有添加到主屏这回事！ 　　12、如何关闭iOS中键盘自动大写 　　我们知道在iOS中，当虚拟键盘弹出时，默认情况下键盘是开启首字母大写的功能的，根据某些业务场景，可能我们需要关闭这个功能，移动版本webkit为input元素提供了autocapitalize属性，通过指定autocapitalize=”off”来关闭键盘默认首字母大写。 　　 　　13、iOS中如何彻底禁止用户在新窗口打开页面 　　有时我们可能需要禁止用户在新窗口打开页面，我们可以使用a标签的target=”_self“来指定用户在新窗口打开，或者target属性保持空，但是你会发现iOS的用户在这个链接的上方长按3秒钟后，iOS会弹出一个列表按钮，用户通过这些按钮仍然可以在新窗口打开页面，这样的话，开发者指定的target属性就失效了，但是可以通过指定当前元素的-webkit-touch-callout样式属性为none来禁止iOS弹出这些按钮。这个技巧仅适用iOS对于Android平台则无效。 　　14、iOS中如何禁止用户保存图片＼复制图片 　　我们在第13条技巧中提到元素的-webkit-touch-callout属性，同样为一个img标签指定-webkit-touch-callout为none也会禁止设备弹出列表按钮，这样用户就无法保存＼复制你的图片了。 　　15、iOS中如何禁止用户选中文字 　　我们通过指定文字标签的-webkit-user-select属性为none便可以禁止iOS用户选中文字。 　　16、iOS中如何获取滚动条的值 　　桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的，但在iOS中你会发现这两个属性是未定义的，为什么呢？因为在iOS中没有滚动条的概念，在Android中通过这两个属性可以正常获取到滚动条的值，那么在iOS中我们该如何获取滚动条的值呢？ 　　通过window.scrollY和window.scrollX我们可以得到当前窗口的y轴和x轴滚动条的值。 　　17、如何解决盒子边框溢出 　　当你指定了一个块级元素时，并且为其定义了边框，设置了其宽度为100％。在移动设备开发过程中我们通常会对文本框定义为宽度100％，将其定义为块级元素以实现全屏自适应的样式，但此时你会发现，该元素的边框(左右)各1个像素会溢了文档，导致出现横向滚动条，为解决这一问题，我们可以为其添加一个特殊的样式-webkit-box-sizing:border-box;用来指定该盒子的大小包括边框的宽度。 　　18、如何解决Android 2.0以下平台中圆角的问题 　　如果大家够细心的话，在做wap站点开发时，大家应该会发现android 2.0以下的平台中问题特别的多，比如说边框圆角这个问题吧。 　　在对一个元素定义圆角时，为完全兼容android 2.0以下的平台，我们必须要按照以下技巧来定义边框圆角： 　　1＼-webkit这个前缀必须要加上（在iOS中，你可以不加，但android中一定要加）； 　　2＼如果对针对边框做样式定义，比如border:1px solid #000;那么-webkit-border-radius这属性必须要出现在border属性后。 　　3＼假如我们有这样的视觉元素，左上角和右上角是圆角时，我们必须要先定义全局的(4个角的圆角值)-webkit-border-radius:5px;然后再依次的覆盖左下角和右下角，-webkit-border-bottom-left-radius:0;-webkit-border-bottom-right-border:0;否则在android 2.0以下的平台中将全部显示直角，还有记住！-webkit这个前缀一定要加上！ 　　19、如何解决android平台中页面无法自适应 　　虽然你的html和css都是完全自适应的，但有一天如果你发现你的页面在android中显示的并不是自适应的时候，首先请你确认你的head标签中是否包含以下meta标签： 　　1 　　<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;" /> 　　 　　如果有的话，那请你再仔细的看清楚有没有这个属性的值width=device-width，如果没有请立即加上吧！ 　　20、如何解决iOS 4.3版本中safari对页面中5位数字的自动识别和自动添加样式 　　新的iOS系统也就是4.3版本，升级后对safari造成了一个bug：即使你添加了如下的meta标签，safari仍然会对页面中的5位连续的数字进行自动识别，并且将其重新渲染样式，也就是说你的css对该标签是无效的。 　　1 　　<meta name="format-detection" content="telphone=no" /> 　　 　　我们可以用一个比较龌龊的办法来解决。比如说支付宝wap站点中显示金额的标签，我们都做了如下改写： 　　1 　　<button class="t-balance"style="background:none;padding:0;border:0;">95009.00</button>元 　　 “答案来源于网络，供您参考” 希望以上信息可以帮到您！

12月17日更新 请问下同时消费多个topic的情况下，在richmap里面可以获取到当前消息所属的topic吗？ 各位大佬，你们实时都是怎样重跑数据的? 有木有大神知道Flink能否消费多个kafka集群的数据？ 这个问题有人遇到吗? 你们实时读取广业务库到kafka是通过什么读的？kafka connector 的原理是定时去轮询，这样如果表多了，会不会影响业务库的性能？甚至把业务库搞挂？ 有没有flink 1.9 连接 hive的例子啊?官网文档试了，没成功 请问各位是怎么解决实时流数据倾斜的？ 请问一下，对于有状态的任务，如果任务做代码升级的时候，可否修改BoundedOutOfOrdernessTimestampExtractor的maxOutOfOrderness呢？是否会有影响数据逻辑的地方呢？ 老哥们有做过统计从0点开始截止到现在时刻的累计用户数吗？ 比如五分钟输出一次，就是7点输出0点到7点的累计用户，7:05输出0点到7:05的累计用户。 但是我这里有多个维度，现在用redis来做的。 想知道有没有更好的姿势？ 实时数仓用什么存储介质来存储维表，维表有大有小，大的大概5千万左右。 各位大神有什么建议和经验分享吗？ 请教个问题，就是flink的窗口触发必须是有数据才会触发吗？我现在有个这样的需求，就是存在窗口内没有流数据进入，但是窗口结束是要触发去外部系统获取上一个窗口的结果值作为本次窗口的结果值！现在没有流数据进入窗口结束时如何触发？ kafkaSource.setStartFromTimestamp(timestamp); 发现kafkasource从指定时间开始消费，有些topic有效，有效topic无效，大佬们有遇到过吗? 各位大佬，flink两个table join的时候，为什么打印不出来数据，已经赋了关联条件了，但是也不报错 各位大佬 请教一下 一个faile的任务 会在这里面存储展示多久啊？ 各位大佬，我的程序每五分钟一个窗口做了基础指标的统计，同时还想统计全天的Uv，这个是用State就能实现吗？ 大佬们，flink的redis sink是不是只适用redis2.8.5版本？ 有CEP 源码中文注释的发出来学习一下吗？ 有没有拿flink和tensorflow集成的？ 那位大神，给一个java版的flink1.7 读取kafka数据，做实时监控和统计的功能的代码案例。 请问下风控大佬，flink为风控引擎做数据支撑的时候，怎么应对风控规则的不断变化，比如说登录场景需要实时计算近十分钟内登录次数超过20次用户，这个规则可能会变成计算近五分钟内登录次数超过20次的。 想了解一下大家线上Flink作业一般开始的时候都分配多少内存？广播没办法改CEP flink支持多流（大于2流）join吗？ 谁能帮忙提供一下flink的多并行度的情况下，怎么保证数据有序 例如map并行度为2 那就可能出现数据乱序的情况啊 请教下现在从哪里可以可以看单任务的运行状况和内存占用情况,flink页面上能看单个任务的内存、cpu 大佬们 flink1.9 停止任务手动保存savepoint的命令是啥？ flink 一个流计算多个任务和 还是一个流一个任务好？ flink 1.9 on yarn， 自定义个connector里面用了jni， failover以后 就起不来了， 报错重复load so的问题。 我想问一下 这个，怎么解决。 难道flink 里面不能用jni吗。 ide里面调试没有问题，部署到集群就会报错了，可能什么问题？ 请教一下对于长时间耗内存很大的任务，大家都是开checkpoint机制，采用rocksdb做状态后端吗？ 请问下大佬，flink jdbc读取mysql，tinyin字段类型自动转化为Boolean有没有好的解决方法 Flink 1.9版本的Blink查询优化器，Hive集成，Python API这几个功能好像都是预览版，请问群里有大佬生产环境中使用这些功能了吗？ 想做一个监控或数据分析的功能，如果我flink 的datastreaming实现消费Kafka的数据，但是我监控的规则数据会增加或修改，但是不想停这个正在运行的flink程序，要如何传递这个动态变化的规则数据，大神给个思路，是用ConnectedStream这个吗？还是用Broadcast ？还有一个，比如我的规则数据是存放在Mysql表中，用什么事件隔30秒去触发读取mysql规则表呢？谢谢！ 想做一个监控或数据分析的功能，如果我flink 的datastreaming实现消费Kafka的数据，但是我监控的规则数据会增加或修改，但是不想停这个正在运行的flink程序，要如何传递这个动态变化的规则数据，大神给个思路，是用ConnectedStream这个吗？还是用Broadcast ？还有一个，比如我的规则数据是存放在Mysql表中，用什么事件隔30秒去触发读取mysql规则表呢？谢谢！ 各位大佬，在一个 Job 计算过程中，查询 MySQL 来补全额外数据，是一个好的实践嘛？还是说流处理过程中应该尽量避免查询额外的数据？ Flink web UI是jquery写的吗？ 12月9日更新 成功做完一次checkpoint后，会覆盖上一次的checkpoint吗？ 数据量较大时，flink实时写入hbase能够异步写入吗？ flink的异步io，是不是只是适合异步读取，并不适合异步写入呀？ 请问一下，flink将结果sink到redis里面会不会对存储的IO造成很大的压力，如何批量的输出结果呢？ 大佬们，flink 1.9.0版本里DataStream api,若从kafka里加载完数据以后，从这一个流中获取数据进行两条业务线的操作，是可以的吗？ flink 中的rocksdb状态怎么样能可视化的查看有大佬知道吗？ 感觉flink 并不怎么适合做hive 中的计算引擎来提升hive 表的查询速度 大佬们，task端rocksdb状态 保存路径默认是在哪里的啊？我想挂载个新磁盘 把状态存到那里去 flink 的state 在窗口滑动到下一个窗口时候 上一个窗口销毁时候 state会自己清除吗？ 求助各位大佬，一个sql里面包含有几个大的hop滑动窗口，如15个小时和24个小时，滑动步长为5分钟，这样就会产生很多overlap 数据，导致状态会很快就达到几百g，然后作业内存也很快达到瓶颈就oom了，然后作业就不断重启，很不稳定，请问这个业务场景有什么有效的解决方案么？ 使用jdbcsink的时候，如果连接长时间不使用 就会被关掉，有人遇到过吗？使用的是ddl的方式 如何向云邪大佬咨询FLink相关技术问题？ 请问各位公司有专门开发自己的实时计算平台的吗？ 请问各位公司有专门开发自己的实时计算平台的吗？ 有哪位大佬有cdh集成安装flink的文档或者手册？ 有哪位大佬有cdh集成安装flink的文档或者手册？ 想问下老哥们都是怎么统计一段时间的UV的？ 是直接用window然后count嘛？ Flink是不是也是这样的？ 请问现在如有个实时程序，根据一个mysql的维表来清洗，但是我这个mysql表里面就只有几条信息且可能会变。 我想同一个定时器去读mysql，然后存在对象中，流清洗的时候读取这个数据，这个想法可行吗？我目前在主类里面定义一个对象，然后往里面更新，发现下面的map方法之类的读不到我更新进去的值 有大佬做过flink—sql的血缘分析吗？ 12月3日更新 请教一下，为什么我flume已经登录成功了keytab认证的kafka集群，但是就是消费不到数据呢？ flink 写入mysql 很长一段时间没有写入，报错怎么解决呢? flink timestamp转换为date类型，有什么函数吗 Run a single Flink job on YARN 我采用这种模式提交任务，出现无法找到 开启 HA 的ResourceManager Failed to connect to server: xxxxx:8032: retries get failed due to exceeded maximum allowed retries number: 0 有大佬遇到过吗 ？ 各位大佬，请问有Flink写S3的方案吗？ flink 连接hbase 只支持1.4.3版本？ onnector: type: hbase version: "1.4.3" 请问 flink1.9能跑在hadoop3集群上吗? 滑动窗口 排序 报错这个是什么原因呢? 这个pravega和kafka有啥区别? flink 开发里数据源配置了RDS，但是在RDS里没有看到创建的表，是为什么呢？ Tumbling Window里的数据，是等窗口期内的数据到齐之后一次性处理，还是到了一条就处理一条啊 双流join后再做time window grouping. 但是双流join会丢失时间属性，请问大家如何解决 stream processing with apache flink，这本书的中译版 现在可以买吗? flink on yarn时，jm和tm占用的内存最小是600M，这个可以修改吗？ 各位大佬，使用默认的窗口Trigger，在什么情况下会触发两次啊？窗口关闭后，然后还来了这个窗口期内的数据，并且开了allowedLateness么？ flink web里可以像storm那样 看每条数据在该算子中的平均耗时吗？ 各位大佬，flink任务的并发数调大到160+以后，每隔几十分钟就会出现一次TM节点连接丢失的异常，导致任务重启。并发在100时运行比较稳定，哪位大佬可以提供下排查的思路？ 感觉stateful function 是下一个要发力的点，这个现在有应用案例吗？ 我有2个子网（a子网，b子网）用vpn联通，vpn几周可能会断一次。a子网有一个kafka集群，b子网运行我自己的flink集群和应用，b子网的flink应用连接到a子网的kafka集群接收消息来处理入库到数仓去。我的问题是，如果vpn断开，flink consumer会异常整个作业退出吗？如果作业退出，我重连vpn后，能从auto checkpoint再把flink应用恢复到出错时flink kafka consumer应该读取的partition/offset位置吗？flink的checkpoint除了保存自己开发的算子里的state，kafkaconsumer里的partition/offset也会保存和恢复吗？ flink的反压为什么不加入metrics呢 hdfs是不是和flink共用一个集群? flink消费kafka，可以从指定时间消费的吗？目前提供的接口只是根据offset消费？有人知道怎么处理？ flink 的Keyby是不是只是repartition而已？没有将key相同的数据放到一个组合里面 电商大屏 大家推荐用什么来做吗？ 我比较倾向用数据库，因为有些数据需要join其他表，flink充当了什么角色，对这个有点迷，比如统计当天订单量，卖了多少钱，各个省的销量，销售金额，各个品类的销售量销售金额 开源1.9的sql中怎么把watermark给用起来，有大神知道吗？ 有没有人能有一些flink的教程 代码之类的分享啊 采用了checkpoint,程序停止了之后，什么都不改，直接重启，还是能接着继续运行吗？如果可以的话，savepoint的意义又是什么呢? 有人做过flink 的tpc-ds测试吗，能不能分享一下操作的流程方法 checkpoint是有时间间隔的，也就可以理解为checkpoint是以批量操作的，那如果还没进行ckecnpoint就挂了，下次从最新的一次checkpoint重启，不是重复消费了？ kafka是可以批量读取数据，但是flink是一条一条处理的，应该也可以一条一条提交吧。 各位大佬，flink sql目前是不是不支持tumbling window join，有人了解吗？ 你们的HDFS是装在taskmanager上还是完全分开的,请问大佬们有遇到这种情况吗？ 大佬们flink检查点存hdfs的话怎么自动清理文件啊 一个128M很快磁盘就满了 有谁遇到过这个问题? 请教一下各位，这段代码里面，我想加一个trigger，实现每次有数据进window时候，就输出，而不是等到window结束再输出，应该怎么加？ 麻烦问下 flink on yarn 执行 客户端启动时 报上面错,是什么原因造成的 求大佬指点 ERROR org.apache.flink.client.program.rest.RestClusterClient - Error while shutting down cluster java.util.concurrent.ExecutionException: org.apache.flink.runtime.concurrent.FutureUtils$RetryException: Could not complete the operation. Number of retries has been exhausted. 大家怎么能动态的改变 flink WindowFunction 窗口数据时间 flink on yarn之后。yarn的日志目录被写满，大家如配置的？ Flink1.9 启动 yarn-session报这个错误 怎么破？ yarn 模式下，checkpoint 是存在 JobManager的，提交任务也是提交给 JobManager 的吧？ heckpoint机制，会不会把window里面的数据全部放checkpoint里面？ Flink On Yarn的模式下，如果通过REST API 停止Job,并触发savepiont呢 jenkins自动化部署flink的job，一般用什么方案？shell脚本还是api的方式？ 各位大佬，开启增量checkpoint 情况下，这个state size 是总的checkpoint 大小，还是增量上传的大小？ 想用状态表作为子表 外面嵌套窗口 如何实现呢 因为状态表group by之后 ctime会失去时间属性,有哪位大佬知道的？ 你们有试过在同样的3台机器上部署两套kafka吗？ 大家有没有比较好的sql解析 组件（支持嵌套sql）? richmapfuntion的open/close方法，和处理数据的map方法，是在同一个线程，还是不同线程调用的？ flink on yarn 提交 参数 -p 20 -yn 5 -ys 3 ，我不是只启动了5个container么？ Flink的乱序问题怎么解决? 我对数据流先进行了keyBy,print的时候是有数据的,一旦进行了timeWindow滑动窗口就没有数据了,请问是什么情况呢? 搭建flinksql平台的时候，怎么处理udf的呀? 怎么查看sentry元数据里哪些角色有哪些权限？ 用java api写的kafka consumer能消费到的消息，但是Flink消费不到，这是为啥? 我state大小如果为2G左右 每次checkpoint会不会有压力? link-table中的udaf能用deltaTrigger么？ flink1.7.2，场景是一分钟为窗口计算每分钟传感器的最高温度，同时计算当前分钟与上一分钟最高温 001 Flink集群支持kerberos认证吗？也就是说flink客户端需要向Flink集群进行kerberos认证，认证通过之后客户端才能提交作业到Flink集群运行002 Flink支持多租户吗？ 如果要对客户端提交作业到flink进行访问控制，你们有类似的这种使用场景吗？ flink可以同时读取多个topic的数据吗？ Flink能够做实时ETL（oracle端到oracle端或者多端）么？ Flink是否适合普通的关系型数据库呢？ Flink是否适合普通的关系型数据库呢？ 流窗口关联mysql中的维度表大佬们都是怎么做的啊? 怎么保证整个链路的exactly one episode精准一次，从source 到flink到sink? 在SQL的TUMBLE窗口的统计中，如果没数据进来的，如何让他也定期执行，比如进行count计算，让他输出0？ new FlinkKafkaConsumer010[String]("PREWARNING",new JSONKeyValueDeserializationSchema(true), kafkaProps).setStartFromGroupOffsets() ) 我这样new 它说要我传个KeyedDeserializationSchema接口进去 flink里面broadcast state想定时reload怎么做？我用kafka里的stream flink独立模式高可用搭建必需要hadoop吗？ 有人用增量cleanupIncrementally的方式来清理状态的嘛，感觉性能很差。 flink sink to hbase继承 RichOutputFormat运行就报错 kafka 只有低级 api 才拿得到 offset 吗？ 有个问题咨询下大家，我的flinksql中有一些参数是要从mysql中获取的，比如我flink的sql是select * from aa where cc=?,这个问号的参数需要从mysql中获取，我用普通的jdbc进行连接可以获的，但是有一个问题，就是我mysql的数据改了之后必须重启flink程序才能解决这个问题，但这肯定不符合要求，请问大家有什么好的办法吗？ flink里怎样实现多表关联制作宽表 flink写es，因为半夜es集群做路由，导致写入容易失败，会引起source的反压，然后导致checkpoint超时任务卡死，请问有没有办法在下游es处理慢的时候暂停上游的导入来缓解反压？ flink 写parquet 文件，使用StreamingFileSink streamingFileSink = StreamingFileSink.forBulkFormat( new Path(path), ParquetAvroWriters.forReflectRecord(BuyerviewcarListLog.class)). withBucketAssigner(bucketAssigner).build(); 报错 java.lang.UnsupportedOperationException: Recoverable writers on Hadoop are only supported for HDFS and for Hadoop version 2.7 or newer 1.7.2 NoWindowInnerJoin这个实现，我看实现了CleanupState可更新过期时间删除当前key状态的接口，是不是这个1.7.2版本即使有个流的key一直没有被匹配到他的状态也会被清理掉，就不会存在内存泄漏的问题了？ flink1.7.2 想在Table的UDAF中使用State，但是发现UDAF的open函数的FunctionContext中对于RuntimeContext是一个private，无法使用，大佬，如何在Table的UDAF中使用State啊？ Flink有什么性能测试工具吗？ 项目里用到了了KafkaTableSourceSinkFactory和JDBCTableSourceSinkFactory。maven打包后，META-INF里只会保留第一个 标签的org.apache.flink.table.factories.TableFactory内容。然后执行时就会有找不到合适factory的报错，请问有什么解决办法吗？ 为什么这个这段逻辑 debug的时候 是直接跳过的 各位大佬，以天为单位的窗口有没有遇到过在八点钟的时候会生成一条昨天的记录? 想问一下，我要做一个规则引擎，需要动态改变规则，如何在flink里面执行？ flink-1.9.1/bin/yarn-session.sh: line 32: construc 我要用sql做一个规则引擎，需要动态改变规则，如何在flink里面执行？ 我要用sql做一个规则引擎，需要动态改变规则，如何在flink里面执行？ 一般公司的flink job有没有进程进行守护？有专门的工具或者是自己写脚本？这种情况针对flink kafka能不能通过java获取topic的消息所占空间大小？ Flink container was removed这个咋解决的。我有时候没有数据的时候也出现这 大家有没有这种场景，数据从binlog消费，这个信息是订单信息，同一个订单id，会有不同状态的变更 问大家个Hive问题，新建的hive外部分区表， 怎么把HDFS数据一次性全部导入hive里 ？ flink里面的broadcast state值，会出现broad流的数据还没put进mapstat Flink SQL DDL 创建表时，如何定义字段的类型为proctime? 请问下窗口计算能对历史数据进行处理吗？比如kafka里的写数据没停，窗口计算的应用停掉一段时间再开起 请问下，想统计未退费的订单数量，如果一个订单退费了（发过来一个update流），flink能做到对结果进行-1吗，这样的需求sql支持吗? 使用Flink sql时,对table使用了group by操作。然后将结果转换为流时是不是只能使用的toRetractStream方法不能使用toAppendStream方法。 百亿数据实时去重，有哪位同学实践过吗？ 你们的去重容许有误差？因为bloom filter其实只能给出【肯定不存在】和【可能存在】两种结果。对于可能存在这种结果，你们会认为是同一条记录？ 我就运行了一个自带的示例，一运行就报错然后web页面就崩了 flink定时加载外部数据有人做过吗？ NoSuchMethodError: org.apache.flink.api.java.Utils.resolveFactory(Ljava/lang/ThreadLocal;Ljava/lang/Object;)Ljava/util/Optional 各位知道这个是那个包吗？ flink 可以把大量数据写入mysql吗？比如10g flink sql 解析复杂的json可以吗？ 在页面上写规则，用flink执行，怎么传递给flink？ 使用cep时，如何动态添加规则？ 如何基于flink 实现两个很大的数据集的交集 并集 差集？ flink的应用场景是？除了实时 各位好，请教一下，滑动窗口，每次滑动都全量输出结果，外部存储系统压力大，是否有办法，只输出变化的key？ RichSinkFunction close只有任务结束时候才会去调用，但是数据库连接一直拿着，最后成了数据库连接超时了，大佬们有什么好的建议去处理吗？？ 为啥我的自定义函数注册，然后sql中使用不了？ 请问一下各位老师，flink flapmap 中的collector.collect经常出现Buffer pool is destroyed可能是什么原因呢？ 用asyncIO比直接在map里实现读hbase还慢，在和hbase交互这块儿，每个算子都加了时间统计 请教一下，在yarn上运行，会找不到 org.apache.flink.streaming.util 请问下大佬，flink1.7.2对于sql的支持是不是不怎么好啊 ，跑的数据一大就会报错。 各位大佬，都用什么来监控flink集群？ flink 有那种把多条消息聚合成一条的操作吗，比如说每五十条聚合成一条 如何可以让checkpoint 跳过对齐呢? 请问 阿里云实时计算（Blink）支持这4个源数据表吗？DataHub Kafka MQ MaxCompute？ 为啥checkpoint时间会越来越长，请问哪位大佬知道是因为啥呢？ 请问Flink的最大并行度跟kafka partition数量有关系吗? source的并行度应该最好是跟partition数量一致吧，那剩下的算子并行度呢？ Flink有 MLIB库吗，为什么1.9中没有了啊？ 请教一下，有没有flink ui的文章呢？在这块内存配置，我给 TM 配置的内存只有 4096 M，但是这里为什么对不上呢？请问哪里可以看 TM 内存使用了多少呢？ 请教个问题，fink RichSinkFunction的invoke方法是什么时候被调用的？ 请教一下，flink的window的触发条件 watermark 小于 window 的 end_time。这个 watermark 为什么是针对所有数据的呢？没有设计为一个 key 一个 watermark 呢？ 就比如说有 key1、key2、key3，有3个 watermark，有 3个 window interval不支持left join那怎么可以实现把窗口内左表的数据也写到下游呢？ 各位 1、sink如何只得到最终的结果而不是也输出过程结果 ；2、不同的运算如何不借助外部系统的存储作为另外一个运算的source 请教各位一个问题，flink中设置什么配置可以取消Generic这个泛型，如图报错： 有大佬在吗，线上遇到个问题，但是明明内存还有200多G，然后呢任务cancel不了，台也取消不了程序 flink遇到The assigned slot container_1540803405745_0094_01_000008_1 was removed. 有木有大佬遇到过。在flink on yarn上跑 这个报错是什么意思呢?我使用滑动窗口的时候出现报错 flink 双流union状态过期不清理有遇到的吗? 大家有没有这种场景，数据从binlog消费，这个信息是订单信息，同一个订单id，会有不同状态的变更，如果订单表与商品明细join查询，就会出现n条重复数据，这样数据就不准了，flink 这块有没有比较好的实战经验的。 大佬们、有没有人遇到过使用一分钟的TumblingEventTimeWindows，但是没有按时触发窗口、而是一直等到下一条消息进来之后才会把这个窗口的数据发送出去的？ flink 有办法 读取 pytorch的 模型文件吗？ 大佬们、有没有人遇到过使用一分钟的TumblingEventTimeWindows，但是没有按时触发窗口、而是一直等到下一条消息进来之后才会把这个窗口的数据发送出去的？ flink timestamp转换为date类型，有什么函数吗 flink 写入mysql 很长一段时间没有写入，报错怎么解决呢? flink 有办法 读取 pytorch的 模型文件吗？ 有没有大佬知道实时报表怎么做？就是统计的结果要实时更新，热数据。 刚接触flink 1.9 求问flink run脚本中怎么没有相关提交到yarn的命令了 请教一下，flink里怎么实现batch sink的操作而不导致数据丢失

没玩过这些，我直接说一下我们公司内部架构的用法把，主要给你讲一下事务 什么叫做事务，不知道你用的是啥数据库，事务就是当前链接下的数据要保持一致性，也就是你上面的所谓的session，我只用Oracle数据库，如果你用过pl/sql的话你每打开一个COMMANDWINDOW他就是一个事务，当前的COMMANDWINDOW做一个数据的增，删，改，如果不提交的话，那么另外一个COMMANDWINDOW里是看不出数据的变化了的，如果需要在另外一个里面看得到数据变化，那么你需要提交事务，使用commit语句，关闭COMMANDWINDOW也就是释放事务 上面的一段配合的只是这么几句代码，我以最简单的JDBC为例 conn=DriverManager.getConnection("jdbc:mysql:///day11","root","root");//获取链接conn.setAutoCommit(false);//开启事务conn.commit();//事务提交conn.rollback();//事务回滚conn.close();//这里是关闭连接 你这里的疑问，我没玩过hibernet，但是大同小异，我以我 公司的内部框架的代码逻辑为例： 如果我是新开启一个事务，也就是你说的 opensession，那么就是新开启一个事务，如果我选择的是获取当前的事务，就是你这边的 getcurrentsession，那么我会做一下判断，当前的线程是否存在事务，如果不存在，我就会新建一个事务，而从你的这个报错看的很清楚，hibernate的获取当前事务的时候，如果不存在当前事务，那么他就直接报错了！ ------菜鸟见解，欢迎拍砖，PS：JDBC的事务控制，回答这个问题的时候我才去百度，以前就一直是记JDBC五步操作，到公司直接用内部框架了，就没去认真研究！ 不要狭义的理解session就是你想的那个session哈 getcurrentsession当前线程的session为了让pojo从数据库到页面到结束使用出于同一session便于hibernate代理,并添加各种操作,事务等保证状态一致, opensession开启一个新session,没有上述特点 spring其实在后面代理了你的hibernate动作,模板保证每个写操作[你配置的情况下]都有事务控制,保证数据一致性[出现异常,事务回滚] 首先明确一点,关系数据库中的事务，核心配置在DB中的由DBA设置，我们在JAVA层的操作准确的说是事务传播属性 首先说一下关系数据库中的事务特性 事务的 特性(ACID特性) A:原子性(Atomicity)    事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做，要么全不做。B:一致性(Consistency)    事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。C:隔离性(Isolation)   一个事务的执行不能被其他事务干扰。D:持续性/永久性(Durability)   一个事务一旦提交，它对数据库中数据的改变就应该是永久性的 然后在事务中存在的问题准确的说是有一些根据不同的隔离级别或业务要求是允许的 1、幻想读：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。2、不可重复读取：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。3、脏读：事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。 引用来自“卧枝会中田”的评论 首先明确一点,关系数据库中的事务，核心配置在DB中的由DBA设置，我们在JAVA层的操作准确的说是事务传播属性 首先说一下关系数据库中的事务特性 事务的 特性(ACID特性) A:原子性(Atomicity)    事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做，要么全不做。B:一致性(Consistency)    事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。C:隔离性(Isolation)   一个事务的执行不能被其他事务干扰。D:持续性/永久性(Durability)   一个事务一旦提交，它对数据库中数据的改变就应该是永久性的 然后在事务中存在的问题准确的说是有一些根据不同的隔离级别或业务要求是允许的 1、幻想读：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。2、不可重复读取：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。3、脏读：事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。

HashMap HashMap 底层是基于 数组 + 链表 组成的，不过在 jdk1.7 和 1.8 中具体实现稍有 不同 其实1.7一个很明显需要优化的地方就是： 当 Hash 冲突严重时，在桶上形成的链表会变的越来越长，这样在查询时的效 率就会越来越低；时间复杂度为 O(N)。 因此 1.8 中重点优化了这个查询效率。 1.8 HashMap 结构图 JDK 1.8 对 HashMap 进行了修改： 最大的不同就是利用了红黑树，其由数组+链表+红黑树组成。 JDK 1.7 中，查找元素时，根据 hash 值能够快速定位到数组的具体下标， 但之后需要顺着链表依次比较才能查找到需要的元素，时间复杂度取决于链 表的长度，为 O(N)。 为了降低这部分的开销，在 JDK 1.8 中，当链表中的元素超过 8 个以后，会 将链表转换为红黑树，在这些位置进行查找的时候可以降低时间复杂度为 O(logN)。 JDK 1.8 使用 Node（1.7 为 Entry） 作为链表的数据结点，仍然包含 key， value，hash 和 next 四个属性。 红黑树的情况使用的是 TreeNode。 根据数组元素中，第一个结点数据类型是 Node 还是 TreeNode 可以判断该位 置下是链表还是红黑树。 核心成员变量于 1.7 类似，增加了核心变量，如下表。 属性说明TREEIFY_THRESHOLD用于判断是否需要将链表转换为红黑树的阈值，默认 为 8。 put步骤： 判断当前桶是否为空，空的就需要初始化（resize 中会判断是否进行初始 化）。 根据当前 key 的 hashcode 定位到具体的桶中并判断是否为空，为空表明没有 Hash 冲突就直接在当前位置创建一个新桶即可。 如果当前桶有值（ Hash 冲突），那么就要比较当前桶中的 key、key 的 hashcode 与写入的 key 是否相等，相等就赋值给 e,在第 8 步的时候会统一进 行赋值及返回。 如果当前桶为红黑树，那就要按照红黑树的方式写入数据。 如果是个链表，就需要将当前的 key、value 封装成一个新节点写入到当前桶的 后面（形成链表）。 接着判断当前链表的大小是否大于预设的阈值，大于时就要转换为红黑树。 如果在遍历过程中找到 key 相同时直接退出遍历。 如果 e != null 就相当于存在相同的 key,那就需要将值覆盖。 后判断是否需要进行扩容. get 方法看起来就要简单许多了。 首先将 key hash 之后取得所定位的桶。 如果桶为空则直接返回 null 。 否则判断桶的第一个位置(有可能是链表、红黑树)的 key 是否为查询的 key，是 就直接返回 value。 如果第一个不匹配，则判断它的下一个是红黑树还是链表。 红黑树就按照树的查找方式返回值。 不然就按照链表的方式遍历匹配返回值。 从这两个核心方法（get/put）可以看出 1.8 中对大链表做了优化，修改为红黑树之 后查询效率直接提高到了 O(logn)。 但是 HashMap 原有的问题也都存在，比如在并发场景下使用时容易出现死循环。 但是为什么呢？简单分析下。 看过上文的还记得在 HashMap 扩容的时候会调用 resize() 方法，就是这里的并 发操作容易在一个桶上形成环形链表；这样当获取一个不存在的 key 时，计算出的 index 正好是环形链表的下标就会出现死循环。 如下图： HashTable HashTable 容器使用 synchronized来保证线程安全，但在线程竞争激烈的情况下 HashTable 的效 率非常低下。 当一个线程访问 HashTable 的同步方法时，其他线程访问 HashTable 的同步方 法可能会进入阻塞或轮询状态。 HashTable 容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有 访问它的线程都必须竞争同一把锁，假如容器里有多把锁，每一把锁用于锁容 器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就 不会存在锁竞争，从而可以有效的提高并发访问效率，这就是 ConcurrentHashMap（JDK 1.7） 使用的 锁分段技术。 ConcurrentHashMap 将数据分成一段一段的存储，然后给每一段数据配一把 锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他 线程访问。 有些方法需要跨段，比如 size() 和 containsValue()，它们可能需要锁定整个表 而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所 有段的锁。 按顺序 很重要，否则极有可能出现死锁，在 ConcurrentHashMap 内部，段数 组是 final 的，并且其成员变量实际也是 final 的，但是，仅仅是将数组声明为 final 的并不保证数组成员也是 final 的，需要实现上的保证。这可以确保不会 出现死锁，因为获得锁的顺序是固定的。 HashTable 的迭代器是强一致性的，而 ConcurrentHashMap 是弱一致的。 ConcurrentHashMap 的 get，clear，iterator 方法都是弱一致性的。 初识ConcurrentHashMap Concurrent翻译过来是并发的意思，字面理解它的作用是处理并发情况的 HashMap。 通过前面的学习，我们知道多线程并发下 HashMap 是不安全的(如死循环)，更普遍 的是多线程并发下，由于堆内存对于各个线程是共享的，而 HashMap 的 put 方法 不是原子操作，假设Thread1先 put 值，然后 sleep 2秒(也可以是系统时间片切换失 去执行权)，在这2秒内值被Thread2改了，Thread1“醒来”再 get 的时候发现已经不 是原来的值了，这就容易出问题。 那么如何避免这种多线程出错的情况呢？ 常规思路就是给 HashMap 的 put 方法加锁(synchronized)，保证同一个时刻只允 许一个线程拥有对 hashmap 有写的操作权限即可。然而假如线程1中操作耗时，其 他需要操作该 hashmap 的线程就需要在门口排队半天，严重影响用户体验， HashTable 就是这样子做的。 举个生活中的例子，很多银行除了存取钱，还支持存取贵重物品，贵重物品都放在 保险箱里，把 HashMap 和 HashTable 比作银行，结构： 把线程比作人，对应的情况如下： 多线程下用 HashMap 不确定性太高，有破产的风险，不能选；用 HashTable 不会 破产，但是用户体验不太好，那么怎样才能做到多人存取既不影响他人存值，又不 用排队呢？ 有人提议搞个「银行者联盟」，多开几个像HashTable 这种「带锁」的银行就好 了，有多少人办理业务，就开多少个银行，一对一服务，这个区都是大老板，开银 行的成本都是小钱，于是「银行者联盟」成立了。 接下来的情况是这样的：比如用户A和用户B一起去银行存各自的项链，这个「银行 者联盟」操作后，然后对用户A说，1号银行现在没人你可以去那存，不用排队，然 后用户A就去1号银行存项链，1号银行把用户A接进门，马上拉闸，然后把用户A的 项链放在第x行第x个保险箱，等用户A办妥离开后，再开闸；对于用户B同理。此时 不管用户A和用户B在各自银行里面待多久都不会影响到彼此，不用担心自己的项链 被人偷换了。这就是ConcurrentHashMap的设计思路，用一个图来理解 从上图可以看出，此时锁的是对应的单个银行，而不是整个「银行者联盟」。分析 下这种设计的特点： 多个银行组成的「银行者联盟」 当有人来办理业务时，「银行者联盟」需要确定这个人去哪个银行 当此人去到指定银行办理业务后，该银行上锁，其他人不能同时执行修改操作，直 到此人离开后解锁. ConcurrentHashMap源码解析 ConcurrentHashMap 同样也分为 1.7 、1.8 版，两者在实现上略有不同。 先来看看 1.7 的实现，下面是结构图： 如图所示，是由 Segment 数组、HashEntry 组成，和 HashMap 一样，仍然是数组 加链表。主要是通过分段锁实现的。 关于分段锁 段Segment继承了重入锁ReentrantLock，有了锁的功能，每个锁控制的是一段， 当每个Segment越来越大时，锁的粒度就变得有些大了。 分段锁的优势在于保证在操作不同段 map 的时候可以并发执行，操作同段 map 的时候，进行锁的竞争和等待。这相对于直接对整个map同步 synchronized是有优势的。 缺点在于分成很多段时会比较浪费内存空间(不连续，碎片化); 操作map时竞争 同一个分段锁的概率非常小时，分段锁反而会造成更新等操作的长时间等待; 当 某个段很大时，分段锁的性能会下降。 1.7 已经解决了并发问题，并且能支持 N 个 Segment 这么多次数的并发，但依然存 在 HashMap 在 1.7 版本中的问题。 那就是查询遍历链表效率太低。 因此 1.8 做了一些数据结构上的调整。 首先来看下底层的组成结构： 其实和 1.8 HashMap 结构类似，当链表节点数超过指定阈值的话，也是会转换成红 黑树的，大体结构也是一样的。 那么 JDK 1.8 ConcurrentHashMap 到底是如何实现线程安全的？ 答案:其中抛弃了原有的Segment 分段锁，而采用了 CAS + synchronized 来保证 并发安全性。（cas：比较并替换） **① 基本组成 ** 抛弃了 JDK 1.7 中原有的 Segment 分段锁，而采用了 CAS + synchronized 来 保证并发安全性。 将JDK 1.7 中存放数据的 HashEntry 改为 Node，但作用是相同的。、 我们来看看 ConcurrentHashMap 的几个重要属性. 重要组成元素 Node：链表中的元素为 Node 对象。他是链表上的一个节点，内部存储了 key、 value 值，以及他的下一 个节点的引用。这样一系列的 Node 就串成一串，组成一 个链表。 ForwardingNode：当进行扩容时，要把链表迁移到新的哈希表，在做这个操作 时，会在把数组中的头节点替换为 ForwardingNode 对象。ForwardingNode 中不 保存 key 和 value，只保存了扩容后哈希表 （nextTable）的引用。此时查找相应 node 时，需要去 nextTable 中查找。 TreeBin：当链表转为红黑树后，数组中保存的引用为 TreeBin，TreeBin 内部不保 存 key/value，他保存了 TreeNode 的 list 以及红黑树 root。 TreeNode：红黑树的节点。 **② put 方法过程 ** 存储结构定义了容器的 “形状”，那容器内的东西按照什么规则来放呢？换句话讲， 某个 key 是按 照什么逻辑放入容器的对应位置呢？ 我们假设要存入的 key 为对象 x，这个过程如下 ： 1、通过对象 x 的 hashCode () 方法获取其 hashCode； 2、将 hashCode 映射到数组的某个位置上； 3、把该元素存储到该位置的链表中。 put 方法用来把一个键值对存储到 map 中。代码如下： 实际调用的是 putVal 方 法，第三个参数传入 false，控制 key 存在时覆盖原来的值。 请先看完代码注释，有个大致的了解，然后我们更加详细的学习一下： 判断存储的 key、value 是否为空，若为空，则抛出异常，否则，进入步骤 2。 计算 key 的 hash 值，随后进入自旋，该自旋可以确保成功插入数据，若 table 表为空或者长度为 0，则初始化 table 表，否则，进入步骤 3。 根据 key 的 hash 值取出 table 表中的结点元素，若取出的结点为空（该桶为 空），则使用 CAS 将 key、value、hash 值生成的结点放入桶中。否则，进入 步骤 4。 若该结点的的 hash 值为 MOVED（-1），则对该桶中的结点进行转移，否则， 进入步骤 5。 5 . 对桶中的第一个结点（即 table 表中的结点）进行加锁，对该桶进行遍历，桶中 的结点的 hash 值与 key 值与给定的 hash 值和 key 值相等，则根据标识选择是 否进行更新操作（用给定的 value 值替换该结点的 value 值），若遍历完桶仍 没有找到 hash 值与 key 值和指定的 hash 值与 key 值相等的结点，则直接新生 一个结点并赋值为之前后一个结点的下一个结点。进入步骤 6。 若 binCount 值达到红黑树转化的阈值，则将桶中的结构转化为红黑树存储， 后，增加 binCount 的值。 如果桶中的第一个元素的 hash 值大于 0，说明是链表结构，则对链表插入或者 更新。 如果桶中的第一个元素是 TreeBin，说明是红黑树结构，则按照红黑树的方式进 行插入或者更新。 在锁的保护下，插入或者更新完毕后，如果是链表结构，需要判断链表中元素 的数量是否超过 8（默认），一旦超过，就需要考虑进行数组扩容，或者是链表 转红黑树。 扩容 什么时候会扩容？ 使用put()添加元素时会调用addCount()，内部检查sizeCtl看是否需要扩容。 tryPresize()被调用，此方法被调用有两个调用点： 链表转红黑树(put()时检查)时如果table容量小于64(MIN_TREEIFY_CAPACITY)，则会 触发扩容。 调用putAll()之类一次性加入大量元素，会触发扩容。 addCount() addCount()与tryPresize()实现很相似，我们先以addCount()分析下扩容逻辑： **1.链表转红黑树 ** 首先我们要理解为什么 Map 需要扩容，这是因为我们采用哈希表存储数据，当固定 大小的哈希表存 储数据越来越多时，链表长度会越来越长，这会造成 put 和 get 的 性能下降。此时我们希望哈希表中多一些桶位，预防链表继续堆积的更长。 ConcurrentHashMap 有链表转红黑树的操作，以提高查找的速度，红黑树时间复 杂度为 O (logn)，而链表是 O (n/2)，因此只在 O (logn)<O (n/2) 时才会进行转换， 也就是以 8 作为分界点。 接下来我们分析 treeifyBin 方法代码，这个代码中会选择是把此时保存数据所在的 链表转为红黑树，还是对整个哈希表扩容。 treeifyBin 不一定就会进行红黑树转换，也可能是仅仅做数组扩容。 构造完TreeBin这个空节点之后，就开始构造红黑树，首先是第一个节点，左右 子节点设置为空，作为红黑树的root节点，设置为黑色，父节点为空。 然后在每次添加完一个节点之后，都会调用balanceInsertion方法来维持这是一 个红黑树的属性和平衡性。红黑树所有操作的复杂度都是O(logn)，所以当元素量比 较大的时候，效率也很高。 **数组扩容 ** 我们大致了解了 ConcurrentHashMap 的存储结构，那么我们思考一个问题，当数 组中保存的链表越来越多，那么再存储进来的元素大概率会插入到现有的链表中， 而不是使用数组中剩下的空位。 这样会造成数组中保存的链表越来越长，由此导致 哈希表查找速度下降，从 O (1) 慢慢趋近于链表 的时间复杂度 O (n/2)，这显然违背 了哈希表的初衷。 所以 ConcurrentHashMap 会做一个操作， 称为扩容。也就是把数组长度变大，增 加更多的空位出来，终目的就是预防链表过长，这样查找的时间复杂度才会趋向于 O (1)。扩容的操作并不会在数组没有空位时才进行，因为在桶位快满时， 新保存元 素更大的概率会命中已经使用的位置，那么可能后几个桶位很难被使用，而链表却 越来 越长了。ConcurrentHashMap 会在更合适的时机进行扩容，通常是在数组中 75% 的位置被使用 时。 其实以上内容和 HashMap 类似，ConcurrentHashMap 此外提供了线程安全的保 证，它主要是通 过 CAS 和 Synchronized 关键字来实现，我们在源码分析中再详细 来看。 我们做一下总结： 1、ConcurrentHashMap 采用数组 + 链表 + 红黑树的存储结构； 2、存入的 Key 值通过自己的 hashCode 映射到数组的相应位置； 3、ConcurrentHashMap 为保障查询效率，在特定的时候会对数据增加长度，这个 操作叫做扩容； 4、当链表长度增加到 8 时，可能会触发链表转为红黑树（数组长度如果小于 64， 优先扩容，具体 看后面源码分析）。 接下来，我们的源码分析就从 ConcurrentHashMap 的构成、保存元素、哈希算 法、扩容、查找数 据这几个方面来进行 扩容后数组容量为原来的 2 倍。 **数据迁移（ 扩容时的线程安全） ** ConcurrentHashMap 的扩容时机和 HashMap 相同，都是在 put 方法的后一步 检查是否需要扩容，如果需要则进行扩容，但两者扩容的过程完全不同， ConcurrentHashMap 扩容的方法叫做 transfer，从 put 方法的 addCount 方法进 去，就能找到 transfer 方法，transfer 方法的主要思路是： 首先需要把老数组的值全部拷贝到扩容之后的新数组上，先从数组的队尾开始 拷贝； 拷贝数组的槽点时，先把原数组槽点锁住，保证原数组槽点不能操作，成功拷 贝到新数组时，把 原数组槽点赋值为转移节点； 这时如果有新数据正好需要 put 到此槽点时，发现槽点为转移节点，就会一直 等待，所以在扩容完成之前，该槽点对应的数据是不会发生变化的； 从数组的尾部拷贝到头部，每拷贝成功一次，就把原数组中的节点设置成转移 节点； 直到所有数组数据都拷贝到新数组时，直接把新数组整个赋值给数组容器，拷 贝完成 putTreeVal()与此方法遍历方式类似不再介绍。  ④ get 方法过程 ConcurrentHashMap 读的话，就比较简单，先获取数组的下标，然后通过判断数 组下标的 key 是 否和我们的 key 相等，相等的话直接返回，如果下标的槽点是链表 或红黑树的话，分别调用相应的 查找数据的方法，整体思路和 HashMap 很像，源 码如下： 计算 hash 值。 根据 hash 值找到数组对应位置: (n – 1) & h。 根据该位置处结点性质进行相应查找。 如果该位置为 null，那么直接返回 null。 如果该位置处的结点刚好就是需要的，返回该结点的值即可。 如果该位置结点的 hash 值小于 0，说明正在扩容，或者是红黑树。 如果以上 3 条都不满足，那就是链表，进行遍历比对即可。 ** 初始化数组 ** 数组初始化时，首先通过自旋来保证一定可以初始化成功，然后通过 CAS 设置 SIZECTL 变量的值，来保证同一时刻只能有一个线程对数组进行初始化，CAS 成功 之后，还会再次判断当前数组是否已经初始化完成，如果已经初始化完成，就不会 再次初始化，通过自旋 + CAS + 双重 check 等 手段保证了数组初始化时的线程安 全，源码如下： 里面有个关键的值 sizeCtl，这个值有多个含义。 1、-1 代表有线程正在创建 table； 2、-N 代表有 N-1 个线程正在复制 table； 3、在 table 被初始化前，代表 根据构造函数传入的值计算出的应被初始化的大小； 4、在 table 被初始化后，则被 设置为 table 大小 的 75%，代表 table 的容量（数组容量）。 initTable 中使用到 1 和 4，2 和 3 在其它方法中会有使用。下面我们可以先看下 ConcurrentHashMap 的构造方法，里面会使用上面的 3 最后来回顾总结下HashMap和ConcurrentHashMap对比 ConcurrentHashMap 和 HashMap 两者的相同之处： 1.数组、链表结构几乎相同，所以底层对数据结构的操作思路是相同的（只是思路 相同，底层实现 不同）； 2.都实现了 Map 接口，继承了 AbstractMap 抽象类，所以大多数的方法也都是相 同的， HashMap 有的方法，ConcurrentHashMap 几乎都有，所以当我们需要从 HashMap 切换到 ConcurrentHashMap 时，无需关心两者之间的兼容问题 不同点： 1.红黑树结构略有不同，HashMap 的红黑树中的节点叫做 TreeNode，TreeNode 不仅仅有属 性，还维护着红黑树的结构，比如说查找，新增等等； ConcurrentHashMap 中红黑树被拆分成 两块，TreeNode 仅仅维护的属性和查找 功能，新增了 TreeBin，来维护红黑树结构，并负责根 节点的加锁和解锁； 2.新增 ForwardingNode （转移）节点，扩容的时候会使用到，通过使用该节点， 来保证扩容时的线程安全。

BRD文档（商业需求文档） 定义：BRD 是英文”Business Requirement Document“的缩写，根据英文直译过来就是”商业需求文档“的意思，指的就是基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。一般来说全新的产品、未来发展有潜力的产品提供BRD！ 真相君：市场前景无限大；用户需求未满足；同类竞品没做到；好机会啊，老板 MRD（市场需求文档） 定义：MRD 是英文”Market Requirements Document“的缩写，根据英文直译过来就是”市场需求文档“的意思，主要是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。一般新功能的实现，上线新的产品提供MRD！ 真相君：老板，市场真的很大，产品路线图我都规划好了，我们按照产品路线发展，肯定能成。 PRD（产品需求文档） 定义：PRD 是英文”Product Requirement Document“的缩写，根据英文直译过来就是”产品需求文档“的意思， PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响产品能否顺利的实施完成。一般产品的功能改善、产品的细节说明提供PRD文档！ 真相君：确保文档可读性；名词不要有歧义；从概念到图纸化；设计开发全靠它。 用户场景 用户场景是什么？是人物、时间、地点、欲望、手段五要素所组成的特定关系。在xx时间（when），xx地点（where），特定类型的用户(who)萌发了某种欲望(desire)，会想通过某种手段(method)来满足欲望。 真相君：产品原型很简单；洞察用户才最难；带入场景去分析；用户心理全了然 MVP 简单的说法就是用最小的成本开发出可表达项目创意、可用且能用于表达核心理念的原型产品，功能极简而且能用于快速验证想法的最小化产品。 真相君：糟了，老板明天要验收；别慌，他不懂技术；咱先拿个半成品忽悠他。 灰度发布 定义：灰度发布（又名金丝雀发布）是指让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。经常与A/B测试一起使用，用于测试选择多种方案。 真相君：不知新版发布会不会挨骂？；找群白鼠测一下；如果反馈还不错；那就逐步推出它。 用户研究 定义：用户研究是指通过对用户的任务操作特性、知觉特征、认知心理特征的研究，使用户的实际需求成为产品设计的导向，使您的产品更符合用户的习惯、经验和期待。 在互联网领域内，用户研究主要应用于两个方面： 对于新产品来说，用户研究一般用来明确用户需求点，帮助设计师选定产品的设计方向； 对于已经发布的产品来说，用户研究一般用于发现产品问题，帮助设计师优化产品体验。 真相君：用户研究不简单；定性定量都精通；还得数据来建模；产品决策要靠它。 用户画像 定义：用户画像就是你的粉丝群体属性的数据，比如性别、学历、职业、收入水平、手机型号、兴趣爱好等等。是根据用户在互联网留下的种种数据，主动或被动地收集，最后加工成一系列的标签。 真相君：平时上网别乱点；行为历史有记录；根据数据贴标签；再想撕掉难上天 A / B测试 定义：AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。 真相君：不知道功能上线后效果好不好，先找一部分用户测试看看，好了再全面推广。 UCD 定义：（User Centered Design）是一种设计思维、模式，指以用户为中心的设计。是在设计过程中以用户体验为设计决策的中心，强调用户优先的设计模式。 真相君：先不要考虑盈利，先让用户用的爽再说。 智能推送 定义：将用户“个性”和“商品、服务、内容”属性进行精准的匹配，达到用户所见即所需所想的目的，缩短了信息触达用户的路径，减少用户流失，促进用户快速转化。 真相君：你想看什么，就给你推送什么。 AIOT 定义：智联网(AIOT，是AI + IOT物联网的结合) 2018年开始崛起，核心是能够运用大量传感设备，综合语音、视觉、动作、温度等数据，实现IOT设备的全自然化的人机交互。 真相君：物联网喊了好多年；体验提升太有限；如今终于有突破；人机交互成关键。 AM敏捷开发 定义：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 真相君：一点点来，不要想一口吃个胖子。 PLC 定义：产品生命周期（Product Life Cycle），简称PLC，是产品的市场寿命，即一种新产品从开始进入市场到被市场淘汰的整个过程。这个过程其实就是经历了一个从“启动、成长、成熟一直到衰退”的阶段。 真相君：一个产品四阶段；阶段策略各不同；快速验证和开发；尽力延长成熟期。 可用性测试 定义：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。 真相君：观察用户使用产品。 商业闭环 定义：商业闭环是围绕着顾客一系列关联性消费需求，逐一提供相应的产品予以满足的商业模式。主要在商业体系中营造循环圈，各个环节都可以相互依靠，既可以作为个体支撑点也可以协同合作。 真相君：产品分步走；逻辑真是乱；怎么讲清楚；就得靠闭环！ 互联网上半场/下半场 定义： 互联网上半场即消费互联网时代，注重的是入口和流量，线上打造； 而下半场即产业互联网时代，注重的是服务和价值，线上线下充分融合。 真相君：上半场玩的是流量，现在流量已经被占完，再看产业和互联；线上线下共融合；下半场来临！ CRUD 创建（Create）、检索（Retrieve）、更新（Update）、删除（Delete），有时候也简称“增删改查”这是面向对象设计中最常用的4个基本方法。说来这是数据库里的必备的知识，但作为互联网公司的产品经理，这也是经常会提起的功能点。 真相君：就是后台功能操作分为：增删改查和搜索。 用户任务的闭环 定义：指的是一系列帮助用户完成任务的环节，这些环节可以应对任务可能出现的各种情况。 真相君：就是用户做一件事情要能做完。 KPI 定义：KPI绩效考核，又称“关键业绩指标”考核法，是企业绩效考核的方法之一。这种方法的优点是标准比较鲜明，易于做出评估。它的缺点是对简单的工作制定标准难度较大，缺乏一定的定量性。 真相君：就是给你分配的任务。 蓝海与红海 定义：所谓蓝海，指的是未知的市场空间，即尚未有人涉足，或是只有极少人涉足并且还没有做出太大成绩的市场。这样的市场，如果成功进入，则会是一段绝佳的时期，因为这段时间内你处于绝对的垄断地位，直到你的竞争对手赶上来。做好核心业务，做足差异化，能够帮助你将你的蓝海时段尽可能地延长，保证你的利益。 所谓红海，指的是已经发展的比较成熟，竞争非常激烈的市场。通常红海里的新人很难在短时间内做出成就，除非你在某一方面比你的竞争对手优势更大，或者你让投资人和初期用户看到了你巨大的发展潜力，又或者你在另一片红海中有着极佳的口碑，现在跨界进入这个行业。 真相君：蓝海就是竞争没那么激烈，红海就是竞争很激烈，刺刀见红。 进入壁垒 定义：进入壁垒值得是进入某一市场的难度，这一高度取决于自身的技术、成本、对特定资源的占有情况，以及对手的发展程度。 真相君：就是进入的门槛到底。 商业价值 定义：商业价值指的是一款产品如何创造价值。 真相君：就是如何赚钱。 墨菲定律 定义：事情如果有变坏的可能，不管这种可能性有多小，它总会发生。 真相君：越怕出事，越会出事。 放到互联网行业通常就是这样： 凡是输入框，都会遭遇灌水、SPAM、脚本注入 凡是积分，都会被刷 凡是推到网站首页的内容，都会出现色情、政治 凡是用户间沟通的渠道，都会被广告机器人利用 而对于项目管理而言，又可能是这样： 一项工作如果只有一个人负责，这个人肯定会休假或者离职 认为没有技术难点的地方，都会成为技术难点或性能瓶颈 羊群效应 定义：头羊往哪里走，后面的羊就跟着往哪里走。 真相君：说白了，其实就是从众心理。 破窗理论 定义：如果有人打坏了一幢建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些示范性的纵容去打烂更多的窗户。 真相君：环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。 二八定律 定义：也叫巴莱多定律，19世纪末20世纪初意大利的经济学家巴莱多认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的。社会约80%的财富集中在20%的人手里，而80%的人只拥有20%的社会财富。80%的回报来源于20%的有效付出。这种统计的不平衡性在社会、经济及生活中无处不在，这就是二八法则。 真相君：一个人的时间和精力都是非常有限的，要想真正做好每一件事情几乎是不可能的，要学会抓住主要矛盾，合理分配我们的时间和精力。要想面面俱到还不如重点突破，把80%的资源花在能出关键效益的20%的方面，这20%的方面又能带动其余80%的发展。 马太效应 定义：指强者愈强，弱者愈弱的现象。《圣经—马太福音》中有一句名言：凡有的，还要加给他，让他有余；没有的，连他所有的，也要夺过来。社会学家从中引申出马太效应这一概念，用以描述社会生活领域中普遍存在的两极分化现象。 真相君：好的愈好，坏的愈坏，多的愈多，少的愈少。

92题 一般来说，建立INDEX有以下益处：提高查询效率；建立唯一索引以保证数据的唯一性；设计INDEX避免排序。 缺点，INDEX的维护有以下开销：叶节点的‘分裂’消耗；INSERT、DELETE和UPDATE操作在INDEX上的维护开销；有存储要求；其他日常维护的消耗：对恢复的影响，重组的影响。 需要建立索引的情况：为了建立分区数据库的PATITION INDEX必须建立； 为了保证数据约束性需要而建立的INDEX必须建立； 为了提高查询效率，则考虑建立（是否建立要考虑相关性能及维护开销）； 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用：加快查询速度。原则：(1) 如果某属性或属性组经常出现在查询条件中，考虑为该属性或属性组建立索引；(2) 如果某个属性常作为最大值和最小值等聚集函数的参数，考虑为该属性建立索引；(3) 如果某属性经常出现在连接操作的连接条件中，考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像，对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言，快照能保证系统的完整性。 89题 游标用于定位结果集的行，通过判断全局变量@@FETCH_STATUS可以判断是否到了最后，通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前，而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行，而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。具体原因为：MySQL使用索引时需要索引有序，假设现在建立了"name，age，school"的联合索引，那么索引的排序为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率，经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话，还需要考虑联合索引中的顺序。此外也要考虑其他方面，比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句，在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句，所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程，不由用户直接调用。创建触发器时会对其进行定义，以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合，涉及特定表或其它对象的任务，用户可以调用存储过程，而函数通常是数据库已定义的方法，它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接，减少复杂 SQL，拆分成简单SQL。减少排序：非必要不排序，利用索引排序，减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or，使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤：选择更优的索引，先分页再Join…。避免类型转换：索引失效。优先优化高并发的 SQL，而不是执行频率低某些“大”SQL。从全局出发优化，而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or，即使其中有条件带索引也不会使用(要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引)。对于多列索引，不是使用的第一部分，则不会使用索引。like查询是以%开头。如果列类型是字符串，那一定要在条件中将数据使用引号引用起来，否则不使用索引。如果mysql估计使用全表扫描要比使用索引快，则不使用索引。例如，使用<>、not in 、not exist，对于这三种情况大多数情况下认为结果集很大，MySQL就有可能不使用索引。 81题 主键不能重复，不能为空，唯一键不能重复，可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键，但可以有很多唯一键。 80题 空值('')是不占用空间的，判断空字符用=''或者<>''来进行处理。NULL值是未知的，且占用空间，不走索引；判断 NULL 用 IS NULL 或者 is not null ，SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0；它们是不等价的。无法使用比较运算符来测试 NULL 值，比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较，该符号与等号作用相似，但对NULL有意义。进行 count ()统计某列的记录数的时候，如果采用的 NULL 值，会被系统自动忽略掉，但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表，他使用保存在内存中的散列索引。一旦服务器重启，所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=，<，>，=>，= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字，可以输入带有单引号的十六进制数字和前缀（X），或者只用（Ox）前缀输入十六进制数字。如果表达式上下文是字符串，则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库里，由mysql_install_db脚本初始化。这些权限表分别user，db，table_priv，columns_priv和host。 76题 在缺省模式下，MYSQL是autocommit模式的，所有的数据库更新操作都会即时提交，所以在缺省情况下，mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话，你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式，在非autocommit模式下，你必须使用COMMIT来提交你的更改，或者用ROLLBACK来回滚你的更改。 75题 它会停止递增，任何进一步的插入都将产生错误，因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引，由于使用b+tree做为索引，以innodb为例，一个树节点的大小由“innodb_page_size”，为了减少树的高度，同时让一个节点能存放更多的值，索引列尽量在整数类型上创建，如果必须使用字符类型，也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下： 限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读。垂直分区： 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。水平分区： 保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException，那么我们就针对这块考虑一下重试，自定义一个注解，用于做切面。针对注解进行切面，设置最大重试次数n，然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞，是通过innodb的行多版本实现的，行多版本并不是实际存储多个版本记录而是通过undo实现（undo日志用来记录数据修改前的版本，回滚时会用到，用来保证事务的原子性）。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎：尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；哈希索引也不支持多列联合索引的最左匹配规则；B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单，一般优先考虑，但float存储的数据范围大，所以范围大的数据就只能用它了，但要注意一些处理细节，因为不精确可能会与自己想的不一致，也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒，datetime与时区无关，存储的范围广(1001-9999)，timestamp与时区有关，存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储，char(4)存储4个字符，根据编码方式的不同占用不同的字节，gbk编码方式，不论是中文还是英文，每个字符占用2个字节的空间，utf8编码方式，每个字符占用3个字节的空间。Varchar保存可变长度的字符串，使用额外的一个或两个字节存储字符串长度，varchar(10),除了需要存储10个字符，还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格，char会自动去掉空格后存储，varchar虽然不会去掉空格，但在进行字符串比较时，会去掉空格进行比较。Varbinary保存变长的字符串，后面不会补\0。 65题 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率，经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话，还需要考虑联合索引中的顺序。此外也要考虑其他方面，比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解：存储过程可以说是一个记录集，它是由一些T-SQL语句组成的代码块，这些T-SQL语句代码像一个方法一样实现一些功能（对单表或多表的增删改查），然后再给这个代码块取一个名字，在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块，执行效率比较高，一个存储过程替代大量T_SQL语句 ，可以降低网络通信量，提高通信速率，可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID，不要使用UUID。因为在InnoDB存储引擎中，主键索引是作为聚簇索引存在的，也就是说，主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序)，如果主键索引是自增ID，那么只需要不断向后排列即可，如果是UUID，由于到来的ID与原来的大小不确定，会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片，进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段，假如申请了char(10)的空间，那么无论实际存储多少内容。该字段都占用10个字符，而varchar是变长的，也就是说申请的只是最大长度，占用的空间为实际字符长度+1，最后一个字符存储使用了多长的空间。在检索效率上来讲，char > varchar，因此在使用中，如果确定某个字段的值的长度，可以使用char，否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted（读取未提交数据） 即便是事务没有commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种。 二. read committed（可以读取其他事务提交的数据）---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据，未提交的数据读不到。 三. repeatable read（可重读）---MySQL默认的隔离级别 当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。 四. serializable（串行化） 其他会话对该表的写操作将被挂起。可以看到，这是隔离级别中最严格的，但是这样做势必对性能造成影响。所以在实际的选用上，我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层，所以查找记录时最多只需要2-4次IO，相对二叉平衡树已经大大降低了。范围查找时，能通过叶子节点的指针获取数据。例如查找大于等于3的数据，当在叶子节点中查到3时，通过3的尾指针便能获取所有数据，而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时，要先记 undo，在记 undo 之前要记 undo 的 redo， 然后修改数据页，再记数据页修改的 redo。 Redo（里面包括 undo 的修改） 一定要比数据页先持久化到磁盘。 当事务需要回滚时，因为有 undo，可以把数据页回滚到前镜像的状态，崩溃恢复时，如果 redo log 中事务没有对应的 commit 记录，那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录，就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统，也就是 redo log 来实现 crash-safe 能力。 55题 重做日志（redo log)      作用：确保事务的持久性，防止在发生故障，脏页未写入磁盘。重启数据库会进行redo log执行重做，达到事务一致性。 回滚日志（undo log)  作用：保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读(MVCC)，也即非锁定读。 二进 制日志（binlog)    作用：用于主从复制，实现主从同步；用于数据库的基于时间点的还原。 错误日志（errorlog) 作用：Mysql本身启动，停止，运行期间发生的错误信息。 慢查询日志（slow query log)  作用：记录执行时间过长的sql，时间阈值可以配置，只记录执行成功。 一般查询日志（general log)    作用：记录数据库的操作明细，默认关闭，开启后会降低数据库性能 。 中继日志（relay log) 作用：用于数据库主从同步，将主库发来的bin log保存在本地，然后从库进行回放。 54题 MySQL有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。死锁的解决办法：1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性(脏读，不可重复读，幻读等)，可能产生死锁。 乐观锁：乐观锁不是数据库自带的，需要我们自己去实现。 悲观锁：在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁：加了共享锁的数据对象可以被其他事务读取，但不能修改。 排他锁：当数据对象被加上排它锁时，一个事务必须得到锁才能对该数据对象进行访问，一直到事务结束锁才被释放。 行锁：就是给某一条记录加上锁。 52题 Mysql是关系型数据库，MongoDB是非关系型数据库，数据存储结构的不同。 51题 关系型数据库优点：1.保持数据的一致性（事务处理）。 2.由于以标准化为前提，数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点：1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点：1、无需经过sql层的解析，读写性能很高。 2、基于键值对，数据没有耦合性，容易扩展。 3、存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，而关系型数据库则只支持基础类型。 缺点：1、不提供sql支持，学习和使用成本较高。 2、无事务处理，附加功能bi和报表等支持也不好。 redis与mongoDB的区别： 性能：TPS方面redis要大于mongodb。 可操作性：mongodb支持丰富的数据表达，索引，redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外（Redis默认的有6种策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种： 1.定时去清理过期的缓存； 2.当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列，一旦消息到达，消费者马上消费，谁先抢到算谁的，如果队列里没有消息，则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道，只要发布者发布消息，所有订阅者都能收到消息，订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列，可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop，blpop/brpop阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列，消息作为value，时间作为score。Zrem 命令用于移除有序集中的一个或多个成员，不存在的成员将被忽略。当 key 存在但不是有序集类型时，返回一个错误。 45题 1.热点数据缓存：因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务：expire 命令设置 key 的生存时间，到时间后自动删除 key。 3.计数器：incrby 命令可以实现原子性的递增。 4.排行榜：借助 SortedSet 进行热点数据的排序。 5.分布式锁：利用 Redis 的 setnx 命令进行。 6.队列机制：有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后，哈希表槽位数（大小）的改变平均只需要对 K/n 个关键字重新映射，其中K是关键字的数量， n是槽位数量。然而在传统的哈希表中，添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点：适合做冷备份；读写服务影响小，reids可以保持高性能；重启和恢复redis进程，更加快速。RDB的缺点：宕机会丢失最近5分钟的数据；文件特别大时可能会暂停数毫秒，或者甚至数秒。 AOF的优点：每个一秒执行fsync操作，最多丢失1秒钟的数据；以append-only模式写入，没有任何磁盘寻址的开销；文件过大时，不会影响客户端读写；适合做灾难性的误删除的紧急恢复。AOF的缺点：AOF日志文件比RDB数据快照文件更大，支持写QPS比RDB支持的写QPS低；比RDB脆弱，容易有bug。 42题 对于Redis而言，命令的原子性指的是：一个操作的不可以再分，操作要么执行，要么不执行。Redis的操作之所以是原子性的，是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的，这也和普通数据库的表现是一样的，可以用incr或者使用Redis的事务，或者使用Redis+Lua的方式实现。对Redis来说，执行get、set以及eval等API，都是一个一个的任务，这些任务都会由Redis的线程去负责执行，任务要么执行成功，要么执行失败，这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单（相对redis只需修改连接端口），对旧项目扩展的首选。(2)codis,目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在节点数改变情况下，旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群，特点在于他的分布式算法不是一致性hash,而是hash槽的概念，以及自身支持节点设置从节点。(4)在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key进行hash计算，然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的代替算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。 40题 (1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件 (2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。 39题 比如订单管理，热数据：3个月内的订单数据，查询实时性较高;温数据：3个月 ~ 12个月前的订单数据，查询频率不高;冷数据：1年前的订单数据，几乎不会查询，只有偶尔的查询需求。热数据使用mysql进行存储，需要分库分表;温数据可以存储在ES中，利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说，一般情况冷数据存储在磁带、光盘，热数据一般存放在SSD中，存取速度快，而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。 37题 分层架构设计，有一条准则：站点层、服务层要做到无数据无状态，这样才能任意的加节点水平扩展，数据和状态尽量存储到后端的数据存储服务，例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中。一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。 35题 redis分布式锁加锁过程：通过setnx向特定的key写入一个随机值，并同时设置失效时间，写值成功既加锁成功；redis分布式锁解锁过程：匹配随机值，删除redis上的特点key数据，要保证获取数据、判断一致以及删除数据三个操作是原子的，为保证原子性一般使用lua脚本实现；在此基础上进一步优化的话，考虑使用心跳检测对锁的有效期进行续期，同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru：当内存不足以容纳写入数据时，从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl：当内存不足以容纳写入数据时，从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random：当内存不足以容纳写入数据时，从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru：当内存不足以容纳写入数据时，从数据集中挑选最近最少使用的数据淘汰。 allkeys-random：当内存不足以容纳写入数据时，从数据集中任意选择数据淘汰。 noeviction：禁止驱逐数据，当内存使用达到阈值的时候，所有引起申请内存的命令会报错。 33题 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿，一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。如何避免：在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。 31题 缓存雪崩，是指在某一个时间段，缓存集中过期失效。大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。而缓存服务器某个节点宕机或断网，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。如何避免：1.redis高可用，搭建redis集群。2.限流降级，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热，在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间。 30题 缓存穿透，是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。一些恶意的请求会故意查询不存在的 key，请求量很大，对数据库造成压力，甚至压垮数据库。 如何避免：1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该 key 对应的数据 insert 了之后清理缓存。2：对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中，查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串，redis 作为其替代者，支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份，即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小：redis最大可以达到1GB，而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置，但是 Spring Boot 中也可以使用 XML 配置，通过spring提供的@ImportResource来加载xml配置。例如：@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族，有众多衍生产品例如Spring Boot，Spring Security等等，但他们的基础都是Spring的IOC和AOP，IOC提供了依赖注入的容器，而AOP解决了面向切面的编程，然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架，主要解决WEB开发的问题，因为 Spring的配置非常复杂，各种xml，properties处理起来比较繁琐。Spring Boot遵循约定优于配置，极大降低了Spring使用门槛，又有着Spring原本灵活强大的功能。总结：Spring MVC和Spring Boot都属于Spring，Spring MVC是基于Spring的一个MVC框架，而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"（YAML 不是一种标记语言）的递归缩写。YAML 的配置文件后缀为 .yml，是一种人类可读的数据序列化语言，可以简单表达清单、散列表，标量等数据形态。它通常用于配置文件，与属性文件相比，YAML文件就更加结构化，而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式： 1.使用springloaded配置pom.xml文件，使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动，配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包，操作简单，但是每次需要重新部署。 用