总述 职位少，要求高，人工智能落地困难，决定了就业可能会是一个大问题 全国范围内的人工智能的职位是183 而Java是10000+ (因lagou并不展示总数，因此该数据从请求分析而来) 因此岗位数量与Java大概是60倍的差距。 应用范围 大数据/机器学习的应用范围是对已有数据进行分析，以得出最优解。或是对已有的房价进行分析，...

职位少，要求高，人工智能落地困难，决定了就业可能会是一个大问题 全国范围内的人工智能的职位是183 而Java是10000+ (因lagou并不展示总数，因此该数据从请求分析而来) 因此岗位数量与Java大概是60倍的差距。 大数据/机器学习的应用范围是对已有数据进行分析，以得出最优解。或是对已有的房价进行分析，已得出明年的可...

Python最近无疑被朋友圈玩坏了 甚至要好几页才能铺下 但从一个资深程序员的视角出发，实在不建议你将Python作为一种职业，从功利性的角度出发，你学Python是很找到工作的 从图片中看出需要Python技能岗位需求量约为Java的1/10, Python基本上只有三种职位后端开发，爬虫，数据挖掘/机器学习，以及运维岗位 就拿后端开发来...

但高低收入差距明显，能写出10W+的小编和普通的小编收入会有数量级的差别，有些头部大V可以单凭一个公众号支持上亿的估值，反之普通运营只是做搬砖工、螺丝钉的工作。

1 快并不是唯一需要考虑的因素等，相对于数据库IO，json解析时间可以忽略不计2 fastjson针对特定需求做了很多优化，导致校验不严格，比如数组[]，夏令时，末尾不带,等都能转成对象3 jackson功能更强大，可配置化程度更高(fastjson)比如序列化guava类型，序列化java8中的时间日期等,常见配置如下

不同与其它中间件框架，Apollo中有大量的业务代码，它向我们展示了大神是如何写业务代码的：maven依赖的层次结构，如何进行基础包配置，以及工具类编写，可以称之为springboot之最佳实践。

1 简单，Apollo是我现在看起来最"简单"的源码不会像spring封装了一层又一层，把人绕晕，而apollo没有那么多封装，上手快，我们学习就应该从简单的开始,凭什么非要去学封的像粽子一样的spring源码，我们就是要去学简简单单，平时朴素，接地气的源码

在《这垃圾APP，差点毁了70万高考生》一文中，我们的报考app是用5W rmb 向供应商采购。在报名当天涌入海量考生，并发数飙升至34W，导致系统宕机，拒绝服务，导致考生无法报名，舆情哗然。

一 规避系统间依赖 任何外部系统都是不可靠的假设你要做的是A系统，某个数据需要到B系统去查。考虑到: 自己系统是有qps指标要求的 其它系统都是不可靠的 那么，是不是必须一定要到B系统呢？能不能做一份数据冗余呢？将B系统中数据同步到自己系统，这样，不管B系统怎么样，自己系统都不会有问题了。 二 尽量是作为依赖提...

上述代码不仅定义了一个队列，并在argument中加入了死信队列，来接受失败消息同时，我们在接受参数时 传入了 channel以及 tag， 这样可以很方便的进行消息回传了，比如: channel.baskAck(...)

如图所示，用户请求都会被包装成一个hytrix请求，hytrix使用ThreadPoolExecutor来管理线程池，一旦超限，就会爆掉比如有30个rps，平均每个请求响应时间为0.2s，那么需要的线程数就是30*0.2=6，然后加上一个附加值，比如说4，6+4=10如果是100rqs，每个响应时间0.2， 100*0.2=20，那就是至少20个线程。当然，此时请求平均...

Java的Volatile的特征是任何读都能读到最新值，本质上是JVM通过内存屏障来实现的，让我们看看从字节码以及汇编码的角度，来看下是否真是如此？

这段代码是用于判断字符串是否相等，但有个奇怪地方是用了i--!=0来做判断，我们通常不是用i++么？为什么用i--呢？而且循环次数相同。原因在于编译后会多一条指令：

Unsafe是Java无锁操作的基石，在无锁并发类中都少不了它们的身影，比如ConcurrentHashMap, ConcurrentLinkedQueue, 都是由Unsafe类来实现的。相对于与Java中的锁，它基本无开销，会原地等待。本文主要介绍下Unsafe中的主要操作。

1984年, 大卫·库伯曾在他的著作《体验学习：体验——学习发展的源泉》提出了学习圈理论，与他认为经验学习过程是由四个适应性学习阶段构成的环形结构，包括具体经验（Concrete Experience），反思性观察（Reflective Observation），抽象概念化（Abstract Conceptualization），主动实践（Active Experimentation）。

经调研，使用Spring Cloud Zuul解决方案的占多数，已经能满足绝大多数公司需求。但除了一些超级公司外，比如阿里，京东，他们是自己撸的一套网关。此外，点评直接采用的nginx负载均衡前置网关，而没用第七层网关，原因据说是七层网关会影响性能，但由于对其架构不甚了解，所以也不得而知。

一 小小推广 讲座 本话题已收入视频讲座《Spring Cloud分布式事务解决方案》大家不妨围观下 开源项目 我们利用消息队列实现了分布式事务的最终一致性解决方案，请大家围观。可以参考Github CoolMQ源码，项目支持网站: [链接]，最新文章或实现会更新在上面 二 前言 阿里2017云栖大会《破解世界性技术难题！GTS让分布式事...

在之前的建立路由中我们改进了日志系统。我们摒弃无脑发送消息的广播路由器，而使用能够根据绑定键(binding key)来发送消息的，从而能有有选择的后去logs.

在订阅/发布中我们建立了一个简单的日志系统，从而将log消息广播给一些消费者。这章我们会在此基础上加入一些新的特性-我们将有针对性的进行消息分发，比如，只把错误(error)消息保存到磁盘，与此同时，打印出所有的消息。

为了更好的阐述这个模式，我们会建立一个新的简单的logging系统，包含2个步骤-第一步发送log信息，第二步能够接受并将信息打印出来，而且在第二步中所有的消费者都会接受到同样的消息，比如一个消费者用来将log信息写到磁盘，另外一个接受信息并显示在屏幕上。因此一旦有有消息，消息会广播到所有的消费者。

在第一篇中我们描述了如何最简单的RabbitMQ操作，如何发送、接受消息。在今天这篇文章中我们将描述如何创建一个任务队列，来将高耗时的任务分发到多个消费者，从而提高处理效率。

公司年终要办一个抢购活动，抢购活动维护有一份名单(txt文件)，只有名单中的用户可以参加抢购活动，所以需要把名单导入到内存数据库中，以便于检验用户是否有资格。

消息队列想必大家都有一定了解：用来解耦，上级模块不用关心下级模块是否执行成功，最常见的比如说日志，核心系统并不关心日志是否成功，日志什么时候记录。这种情形就可以用消息队列来解耦。

Rabbitmq舍弃了繁重的事务消息而使用了消息确认机制实现了分布式事务，实在是解耦之一大神器。但是其配置起来挺麻烦，各种参数，各种调整。但国内貌似资料很少，找来找去都找不到，自己撸一发先

经调研发现这绝对是一个坑，pv、uv统计存在的设计看起来简单，但是瞬间流量大，特别是有抢购等功能时，设计不良会导致数据库访问压力大，还存在被用心不良者利用等情况。

储存用户余额资产。比如返现活动等，例如评价返现30元，一般我们都是返到用户余额；另外一些项目有充值需求，也可以把第三方支付结构或者银行机构内的资金充值到余额中。

spring-boot中可以用@validated来校验数据，如果数据异常则会统一抛出异常，方便异常中心统一处理。比如，我们判断一个输入参数是否合法，可以用如下方式

Cache通常意义上是指高速缓存，它与数据库最大的区别是“更快”，可能会快上100倍，而且Cache是全部运行在内存中，而数据库中的数据一般都是存在硬盘中，而IO一直都是网站等大规模系统的瓶颈，如果不使用Cache，完全用数据库，当访问量过大时将导致数据丢失，更严重时会导致系统崩溃，特别是遇到恶意攻击的情况，所以缓存...

分布式系统最终一致性有N种方案，比如2PC（2阶段事务） ，以及三段提交等等，但开销较大，实现起来复杂，比如2阶段事务为例，需要引入一个协调者（Coordinator）来统一掌控所有参与者（Participant）的操作结果

结论：所有判断都用=== 而不用 == ，除了判断 x == null，因为即将 x == null 是 x === null || x === undefined 的缩写。