All posts by dotte

现代 JS 流程控制:从回调函数到 Promises 再到 Async/Await

原文链接:Flow Control in Modern JS: Callbacks to Promises to Async/Await

译者:OFED

JavaScript 通常被认为是异步的。这意味着什么?对开发有什么影响呢?近年来,它又发生了怎样的变化?

看看以下代码:

大多数编程语言同步执行每行代码。第一行执行完毕返回一个结果。无论第一行代码执行多久,只有执行完成第二行代码才会执行。

单线程处理程序

JavaScript 是单线程的。当浏览器选项卡执行脚本时,其他所有操作都会停止。这是必然的,因为对页面 DOM 的更改不能并发执行;一个线程
重定向 URL 的同时,另一个线程正要添加子节点,这么做是危险的。

用户不容易察觉,因为处理程序会以组块的形式快速执行。例如,JavaScript 检测到按钮点击,运行计算,并更新 DOM。一旦完成,浏览器就可以自由处理队列中的下一个项目。

(附注: 其它语言比如 PHP 也是单线程,但是通过多线程的服务器比如 Apache 管理。同一 PHP 页面同时发起的两个请求,可以启动两个线程运行,它们是彼此隔离的 PHP 实例。)

通过回调实现异步

单线程产生了一个问题。当 JavaScript 执行一个“缓慢”的处理程序,比如浏览器中的 Ajax 请求或者服务器上的数据库操作时,会发生什么?这些操作可能需要几秒钟 – 甚至几分钟。浏览器在等待响应时会被锁定。在服务器上,Node.js 应用将无法处理其它的用户请求。

解决方案是异步处理。当结果就绪时,一个进程被告知调用另一个函数,而不是等待完成。这称之为回调,它作为参数传递给任何异步函数。例如:

doSomethingAsync() 接收回调函数作为参数(只传递该函数的引用,因此开销很小)。doSomethingAsync() 执行多长时间并不重要;我们所知道的是,callback1() 将在未来某个时刻执行。控制台将显示:

回调地狱

通常,回调只由一个异步函数调用。因此,可以使用简洁、匿名的内联函数:

一系列的两个或更多异步调用可以通过嵌套回调函数来连续完成。例如:

不幸的是,这引入了回调地狱 —— 一个臭名昭著的概念,甚至有专门的网页介绍!代码很难读,并且在添加错误处理逻辑时变得更糟。

回调地狱在客户端编码中相对少见。如果你调用 Ajax 请求、更新 DOM 并等待动画完成,可能需要嵌套两到三层,但是通常还算可管理。

操作系统或服务器进程的情况就不同了。一个 Node.js API 可以接收文件上传,更新多个数据库表,写入日志,并在发送响应之前进行下一步的 API 调用。

Promises

ES2015(ES6) 引入了 Promises。回调函数依然有用,但是 Promises 提供了更清晰的链式异步命令语法,因此可以串联运行(下个章节会讲)。

打算基于 Promise 封装,异步回调函数必须返回一个 Promise 对象。Promise 对象会执行以下两个函数(作为参数传递的)其中之一:

  • resolve:执行成功回调
  • reject:执行失败回调

以下例子,database API 提供了一个 connect() 方法,接收一个回调函数。外部的 asyncDBconnect() 函数立即返回了一个新的 Promise,一旦连接创建成功或失败,resolve() 或 reject() 便会执行:

Node.js 8.0 以上提供了 util.promisify() 功能,可以把基于回调的函数转换成基于 Promise 的。有两个使用条件:

  1. 传入一个唯一的异步函数
  2. 传入的函数希望是错误优先的(比如:(err, value) => …),error 参数在前,value 随后

举例:

各种库都会提供自己的 promisify 方法,寥寥几行也可以自己撸一个:

异步链式调用

任何返回 Promise 的函数都可以通过 .then() 链式调用。前一个 resolve 的结果会传递给后一个:

同步函数也可以执行 .then(),返回的值传递给下一个 .then()(如果有)。

当任何一个前面的 reject 触发时,.catch() 函数会被调用。触发 reject 的函数后面的 .then() 也不再执行。贯穿整个链条可以存在多个 .catch() 方法,从而捕获不同的错误。

ES2018 引入了 .finally() 方法,它不管返回结果如何,都会执行最终逻辑 – 例如,清理操作,关闭数据库连接等等。当前仅有 Chrome 和 Firefox 支持,但是 TC39 技术委员会已经发布了 .finally() 补丁

使用 Promise.all() 处理多个异步操作

Promise .then() 方法用于相继执行的异步函数。如果不关心顺序 – 比如,初始化不相关的组件 – 所有异步函数同时启动,直到最慢的函数执行 resolve,整个流程结束。

Promise.all() 适用于这种场景,它接收一个函数数组并且返回另一个 Promise。举例:

任意一个异步函数 rejectPromise.all() 会立即结束。

使用 Promise.race() 处理多个异步操作

Promise.race() 与 Promise.all() 极其相似,不同之处在于,当首个 Promise resolve 或者 reject 时,它将会 resolve 或者 reject。仅有最快的异步函数会被执行:

前途光明吗?

Promise 减少了回调地狱,但是引入了其他的问题。

教程常常不提,整个 Promise 链条是异步的,一系列的 Promise 函数都得返回自己的 Promise 或者在最终的 .then().catch() 或者 .finally() 方法里面执行回调。

我也承认:Promise 困扰了我很久。语法看起来比回调要复杂,好多地方会出错,调试也成问题。可是,学习基础还是很重要滴。

延伸阅读:

Async/Await

Promise 看起来有点复杂,所以 ES2017 引进了 async 和 await。虽然只是语法糖,却使 Promise 更加方便,并且可以避免 .then() 链式调用的问题。看下面使用 Promise 的例子:

使用 async / await 重写上面的代码:

  1. 外部方法用 async 声明
  2. 基于 Promise 的异步方法用 await 声明,可以确保下一个命令执行前,它已执行完成

await 使每个异步调用看起来像是同步的,同时不耽误 JavaScript 的单线程处理。此外,async 函数总是返回一个 Promise 对象,因此它可以被其他 async 函数调用。

async / await 可能不会让代码变少,但是有很多优点:

  1. 语法更清晰。括号越来越少,出错的可能性也越来越小。
  2. 调试更容易。可以在任何 await 声明处设置断点。
  3. 错误处理尚佳。try / catch 可以与同步代码使用相同的处理方式。
  4. 支持良好。所有浏览器(除了 IE 和 Opera Mini )和 Node7.6+ 均已实现。

如是说,没有完美的…

Promises, Promises

async / await 仍然依赖 Promise 对象,最终依赖回调。你需要理解 Promise 的工作原理,它也并不等同于 Promise.all() 和 Promise.race()。比较容易忽视的是 Promise.all(),这个命令比使用一系列无关的 await 命令更高效。

同步循环中的异步等待

某些情况下,你想要在同步循环中调用异步函数。例如:

不起作用,下面的代码也一样:

循环本身保持同步,并且总是在内部异步操作之前完成。

ES2018 引入异步迭代器,除了 next() 方法返回一个 Promise 对象之外,与常规迭代器类似。因此,await关键字可以与 for ... of 循环一起使用,以串行方式运行异步操作。例如:

然而,在异步迭代器实现之前,最好的方案是将数组每项 map 到 async 函数,并用 Promise.all() 执行它们。例如:

这样有利于执行并行任务,但是无法将一次迭代结果传递给另一次迭代,并且映射大数组可能会消耗计算性能。

丑陋的 try/catch

如果执行失败的 await 没有包裹 try / catchasync 函数将静默退出。如果有一长串异步 await 命令,需要多个 try / catch 包裹。

替代方案是使用高阶函数来捕捉错误,不再需要 try / catch 了(感谢@wesbos的建议):

当应用必须返回区别于其它的错误时,这种作法就不太实用了。

尽管有一些缺陷,async/await 还是 JavaScript 非常有用的补充。更多资源:

JavaScript 之旅

异步编程是 JavaScript 无法避免的挑战。回调在大多数应用中是必不可少的,但是容易陷入深度嵌套的函数中。

Promise 抽象了回调,但是有许多句法陷阱。转换已有函数可能是一件苦差事,·then() 链式调用看起来很凌乱。

很幸运,async/await 表达清晰。代码看起来是同步的,但是又不独占单个处理线程。它将改变你书写 JavaScript 的方式,甚至让你更赏识 Promise – 如果没接触过的话。

微信小程序开发资源汇总

QQ交流群

目录

推荐

置顶

官方文档

工具

  • WePY ★12k+ – 支持组件化的小程序开发框架
  • mpvue ★11k+ – 基于 Vue.js 的小程序开发框架,从底层支持 Vue.js 语法和构建工具体系
  • Taro ★3.9k – 使用 React 的方式开发小程序的框架,同时支持生成多端应用
  • Labrador ★1.5k – 支持 ES6/7 的微信小程序组件化开发框架
  • wept ★1.8k – 微信小程序实时运行环境
  • wafer ★1.6k – 快速构建具备弹性能力的微信小程序
  • wechat_web_devtools ★600+ – Linux 下微信开发者工具
  • minapp ★400+ – TypeScript 版小程序开发框架(兼容原生小程序代码)
  • tina ★300+ – 轻巧的渐进式微信小程序框架
  • xpmjs ★100+ – 微信小程序云端增强 SDK
  • WeApp-Workflow ★100+ – 基于 Gulp 的微信小程序前端开发工作流
  • gulp-wxa-copy-npm – 微信小程序 gulp 插件,解决 npm 包管理和 babel-runtime
  • weact – 用 JSX 快速开发小程序
  • socket.io-mp-client – 微信小程序 socket.io 客户端
  • wxa – 方便的小程序开发框架
  • px2rpx – Px 转 Rpx 在线工具
  • wxml-parser – JavaScript WXML parser
  • weappx – 基于 redux 的数据层管理框架
  • weapp-start – 基于插件机制的开发脚手架,改善原生小程序开发体验
  • Egret Wing – 支持微信小程序实时预览的 IDE
  • wxapp-graphql – 小程序GraphQL客户端

插件

教程

视频教程

文章

组件

Demo

from:https://github.com/justjavac/awesome-wechat-weapp

中国互联网20年简史(1998-2018),告诉你本质是什么、规律是什么

我先说说互联网三大支柱:

1、内容:新闻&文学、音乐&视频

2、社区+内容

3、游戏

4、电子商务

我们来简单回顾一下中国互联网20年。咱们先从1998年开始。

一、1998年:内容门户元年

1998年2月,张朝阳正式成立搜狐。给中国产业带来了VC风险投资、CXO职业经理人团队,让中国老百姓认知了中国互联网。

1998年,四通利方和北美华人网华渊网合并,成立新浪网。给中国产业带来了并购、创始人被踢出团队。

1997年,网易成立。1998年推出网易免费电子邮件服务。

显然,这是内容门户之年。

虽然1998年腾讯也成立了,但显然大家都没注意到它。但最后四大门户是:搜狐、新浪、网易、腾讯。

还有一家公司成立,那就是在线网络游戏公司:联众,出自希望公司UCDOS软件团队。

你看,内容门户+BBS论坛社区+IM+游戏,在20年前,就同时出现了。中国互联网主航道,都基本出现。

二、1999年:电子商务元年

内容门户大热到极点。连联想都做了一个FM365。更别说还有中华网、TOM网、多来米这些富家子弟玩的。这些显然都是后知后觉了。

1999年11月,当当B2C成立,标品卖书,客单价也低,正好做启蒙。1999年,阿里巴巴B2B也成立了,搞黄页,帮助中国小商品制造出口走向国际。

1999年还成立了一家当时没人知道的公司:携程。

1999年还成立了一家公司:51job,网上找工作。其实招聘的本质是:黄页信息,只不过这个黄页不是企业信息,而是个人简历信息。

这是中国电子商务的开始。他们真是先知先觉。

三、2000年:内容门户上市年

网易、搜狐、新浪都在纳斯达克上市。这才短短3年时间。

2000年1月,百度成立。

四、2001年:移动手机元年

美国互联网投资泡沫破裂,也影响了中国。很多后来进入者都纷纷转型去开发企业软件,因为他们熟悉互联网、熟悉当时火热的Web开发技术和JAVA开发技术,所以他们一开始就做供应链互联网平台。当时中国企业软件商还在纷纷用VB/PB/DELPHI开发局域网企业内部管理软件呢。

但是在前几年互联网资本的推动下,基础设施:通信&数据传输网络也在迅猛发展。诺基亚在这一年市值逼近2500亿美金,中国出现国产手机热,以波导为代表,IT厂商联想也介入进来,家电厂商海尔也介入,电话座机厂商步步高(Vivo和Oppo的母公司)也介入。

五、2002年:移动手机内容SP元年

2002年,中国移动和中国联通的手机终于能短信互通了。好不容易2000年上市的三大门户都熬的受不了,想寻找到立刻变现的业务。

彩铃、短信报热。网易首先抓住这个机遇(嘿嘿,大家可以另外寻找网易和张静君和广州电信局的渊源)。中国互联网企业做SP业务开始了,尤其是把网上的新闻和段子通过短信传播。

六、2003年:网络游戏元年

2003年7月,盛大公司发布传奇世界游戏,引发了中国网络游戏热。随后,九城、完美时空、巨人等等公司跟进,造就了中国很多赚的盆满钵满的网络游戏公司。这个行当也给中国积累了大量的产品经理、制作人、美工人才、音效人才、3D技术、网络技术。

七、2004年:中国互联网第一波集中上市收割年

2004年,移动手机内容SP厂商:空中网、掌上灵通网,上市。

2004年,垂直金融内容门户公司:金融界,上市

2004年,社区+IM+游戏厂商腾讯上市。

2003年12月(相当于2004年了吧),中国电子商务第一个公司:携程,上市。携程。从1999年中国电子商务开始元年,到2003年,这才短短4年时间。

2004年,泛电商人才招聘网:51job上市。

2004年,网上卖机票电商网:E龙上市。

2004年,网络游戏厂商:盛大,上市。

从1998年算来,到2004年,6年时间,中国互联网开始了第一波收割热潮。

八、2005年:Web2.0社区内容元年

2005年,超女最火的一届出现:李宇春、张靓颖、何洁。大众用短信投票引爆全国。这是民众的、互动的狂欢。

2005年,新浪博客发布。

2005年3月,豆瓣成立。这是一个点评的网站。

2005年12月,58同城成立,这是一个个人黄页发布的网站。

额外,搜索引擎公司:百度,在这一年上市了。

七、2006年:网络视频内容元年

2006年,六间房视频网成立。2006年,李善友的酷六网成立。2006年,优酷网成立。2006年,Google并购Youtube网。

另外,2005年4月,土豆网成立。2005年,迅雷公司正式成立。2005年,VeryCD(电驴下载)公司正式成立。这都是和视频电影的崛起有关联的。

过去大家只能看文字图片内容网站,做图片钻展广告。现在有了更直观的视频网站,而且每部电影都可以贴片做广告了。

但是并不代表文字内容网站失落,相反,中国网络文学崛起,你看:2006年,天下霸唱开始写鬼吹灯引爆盗墓类小说、2006年当年明月开始写明朝那些事儿引爆写史类小说,2006年月关开始写回到明朝当王爷引爆穿越类小说。

2006年,其实还有一个大混战,就是楼宇广告大战。成立于2003年的分众传媒,2005年上市,2006年并购了聚众传媒、框架传媒。

八、2007年:电子商务高速成长年

2007年,阿里巴巴B2B业务在香港上市。

但是大家也别忘了,2007年8月,中关村一个经营了快10年的拥有11家线下店铺IT硬件批发零售商,融了一笔钱,开始关闭自己的线下店,专注高速发展线上电商自营零售,那就是京东。

2007年,Yes!PPG成立,主打自创品牌的男士商务休闲服装。2007年,模仿Yes!PPG的凡客诚品也成立了。这是中国自创品牌的电子商务公司,集:研发设计、供应链采购、委托加工、质量控制、商品电商零售、仓储物流配送于一体。

2007年,也是中国快捷酒店大战的一年。如家、汉庭、锦江之星、7天、莫泰、格林豪泰、布丁、桔子酒店…,好多好多。

悄悄另外说一句:2007年,iPhone上市了,大内存、高速CPU、高速WIFI网络、大屏幕、多点触摸输入操作,这几乎是和过去的智能手机有天壤差别:小内存、小屏幕、GPRS联网、笔触输入或键盘输入。中国移动互联网暗示着要大规模爆发了。

九、2008年:智能手机元年

2008年,是中国互联网的十周年。但是这一年也暗示着,中国PC Web互联网即将开始走向最高峰,最高峰也意味着下一个时代已经在悄然启动。

2008年,Google正式发行Android操作系统。

2008年,Apple发布iPhone3G手机,最最关键的是,智能手机的高利润盈利模式、流量口模式出现了:App Store。想想百度收购91,其实也想占领智能移动互联网的入口,没想到独立的应用商店根本不存在活路,全被智能手机厂商在底层釜底抽薪了,人家有小米应用商店、华为应用商店…,全是硬件+软件一体化的。

2008年,山寨手机热啊。在联发科一体化MTK模组的支持下,在华强北电子零件集散批发、深圳电子代工场云集的支撑下,中国人制造手机的门槛被放到最低。

十、2009年:交战年

2009年,新浪微博发布显然是最显眼的。随后,各大内容门户网站纷纷发布类微博产品服务。微博,120个字,类似短信使用体验却可以带图片(比短信好),可以关注名人还可以评论互动(不像QQ得双向关注),也可以随手转发。

除了微博这种类互联网手机上的多媒体短信产品大战,这一年整个互联网界都不平静。

淘宝发布购物搜索,屏蔽百度爬虫。当然,微软也发布了Bing搜索引擎来PKGoogle搜索引擎。

腾讯和搜狗针对输入法进行诉讼。因为输入法在用户需求探知、弹窗引流、输入汉字导流方面具有很高的入口杀伤力。

网络游戏《魔兽》的代理运营权,也在九城、网易之间拉锯。

还有2008年很火的基于QQ社交网络关系的页游:偷菜,开心网和千橡开心网也进行了诉讼。

为什么2009年如此不平静?就是因为PC Web互联网进入成熟期,产业要开始高度集中,要进行整合,不可避免要咔咔作响。

2009年,中国三大运营商均获得3G牌照,移动互联网眼看着眼看着要来临了。

十一、2010:电商爆发年

2010年大家最记忆犹新的肯定是百团大战,大量团购网站出现,尤其以2010年3月美团成立为标志。中国电子商务:衣食住行,衣,有淘宝;食开始了,就是这些团购网;住,有曾经的如家快捷酒店大战,也有58的租房二手房黄页广告聚焦房产行业大战;行,有过去的携程、E龙、同程、去哪儿大战。除了衣是实物零售业外,其他食住行都是服务电商业,即:在网上吸引消费者流量,在网上获得优惠折扣,在网上下订单,甚至在网上进行支付,然后在线下进行到场消费。

2010年,在衣这个事情上,还有一个轰动的事,那就是淘宝双十一热。但这已经其实是第二届了(第一届是2009年双11),但就如超女一样,也是第一届举办完了大部分人都不知道,第二届才引爆。双11对于淘宝的意义非常大。而京东,在2010年也迎来了爆发式增长:开放POP平台、一线城市极速达、收购网银在线介入金融业务。而且京东主动发起了图书大战,直指当当老大哥(当当可谓是中国互联网最早的电商零售)。还有一家发源于手册邮寄购买最终爆发于电商的服装零售公司:麦考林,也在2010年上市了,成为了第一家上市的电子商务零售公司(2007年阿里巴巴B2B业务上市。)

1999年,中国电商元年;2007年,中国电商成长年;2010年,中国电商爆发年。

当然,在PCWeb纯互联网领域,2010年也发生了一件非常大的事情,就好像两个黑洞碰撞一样巅峰对决,那就是3Q大战。2010年11月21日,在工信部、网信办的协调下,两个公司达成和解,不互相封杀卸载对方的软件。中国PC 互联网终于走到了尽头。就好像红巨星要爆炸要产生超新星是一样一样的。从1998年开始的PC Web互联网,走到了2008年智能手机元年,2009年互联网产业整合交战,最终在2010年3Q大战最高巅峰对决中收场。

再想想中国移动互联网,2008年是智能手机元年,今年是2018年,也十年了,今年的大战是腾讯集团和今日头条的大战。相信到2020年,也会如超新星一样,那时候是什么互联网呢?已经有了ADSL宽带PC Web 互联网和4G 移动 App互联网,难道那时候在5G的引导下,会出现万物互联网?

4G移动App互联网,以移动智能手机为主产业,那5G万物互联网,什么是主产产业呢?难道是智能汽车?

十二、2011:中国移动互联网元年

这一年,有两个重要级产品出现,一个是智能手机:小米和MIUI OS出现,一个是原生移动IM:微信出现。

智能手机硬件、Andriod操作系统、应用商店、IM通信,这种组合层次颇值得人寻味。在万物互联网时代会不会出现的最初超级应用也是这样?

其实早在2G GPRS时代,在2008年,手机QQ已经很多人使用了,但是微信出现了,手机QQ没落了。微信的出现正好和iPhone成为智能手机事实标准是同步的。从iPhone开始,过去手机是五花八门各种样子各种功能,尤其在山寨手机之时到达最高潮,然后在iPhone带动下,全世界的手机都变成一模一样的大体模样了。也就是说,都是大屏幕、无键盘。微信的崛起第一步就是:语音消息、手机通讯录导入、摇一摇周边。你看,全是原生应用了手机的独特特性。大家在思考万物互联网的时候也应该这样思考,要充分应用硬件的独特特性,而不是把大象装在冰箱里(比如很多人把企业管理软件精简功能做成App)。

十三、2012年:中国移动互联网发展年

这一年,中国手机网民数量超过了电脑上网网民数量(其实2013年中国政府才要求运营商强力推4G)。

这一年,中国移动互联网高速发展,大家都纷纷把自己的PC Web互联网的功能翻新成App版本。

华为、锤子也正式宣布进入智能手机领域。360和海尔也联合推出超级战舰手机。就连腾讯也谨慎的做了一个手机ROM。大家纷纷想从智能手机硬件、智能路由器和DNS、OS、应用商店、通信IM超级APP,一层层地釜底抽薪。

十四、2013:中国移动互联网爆炸年

3年啊,同志们。太快了,怪不得劳模雷军说:现在就连睡觉都觉得是浪费。

这一年,小米开始构建自己的智能产品生态,发布了好几款智能产品。这一年,乐视智能电视发布,乐视开始引爆江湖。

在这一年有两个关键事件决定了这一年是移动互联网爆炸年。一个是微信发布了游戏流量入口、打飞机小游戏狂潮掀起了移动游戏App的热潮。移动互联网,怎么能够少了游戏这一个半边天呢。微信在这一年还发布了公众号。没有媒体人的卷入,就不可能有大影响力大声音。微信也是在这一年狂发展的。

另外一个大事件就是,也就是从这一年开始,BAT们都开始做好自己的主流超级流量App,大力发展Open API开放平台,大力做投资并购。中国移动互联网为什么发展的这么快,关键就是有三大要素:超级流量、Open API和平台、资本投资和并购进入山头帮派时代。同志们,这句话要标红啊。这是过去中国互联网界从未有过的事情啊。这是中国互联网的并购年,其中最大的收购案就是百度以18.5亿美金收购91无线。

十五、2014:中国企业服务元年

在这一年,中国电商出现了一件大事:京东、阿里纷纷上市。京东和阿里占据中国线上B2C零售80%市场份额,构成了真正的双子星结构。这种市场结构,意味着这个市场已经成为寡头市场。现在再进入这个市场,不可能再出现第三巨头了,从第三名到最后一名,所有加总才能占据最多20%市场。从目前来看,就连拼多多这种拼团模式、云集微店众包销售模式,也只能成诸侯而不能成王。

虽然说,云计算创业三小龙:Ucloud、七牛、青云,都是2010-2011间成立的。但是,中国企业服务投资规模第一波热潮却真正来自2014年。其实不说2006年Amazon发布AWS,就说阿里云,也是在2009年10月写下第一行代码,2012年做天猫聚石塔项目,2013年换帅胡晓明开始高速发展。而中国IaaS云计算的高潮,还要等到2016年,那一年,所有互联网大佬、所有中国系统集成商大佬都已经进入IaaS公有云和私有云的市场。不过很多人却还后知后觉,直到2015年中国企业服务投资最高潮,很多人才匆忙杀入了这个行业,才匆忙升级要做SaaS软件。

这一年还有件事,就是菜鸟网络在这年成立了。菜鸟网络不搞仓库不买卡车不跑运输不招业务人员,但是菜鸟网络凭借淘宝天猫的订单流量、凭借自己的大数据建模技术,来做到智能的仓储物流调度,抽取中间的调度佣金。这本质上是电商+企业服务的混合体。

这一年还有件事,是滴滴的快速崛起。滴滴后来被人们笑话段子都演变成了滴滴模式(拼多多拼团也是种模式、团购秒杀倒计时也是种模式),什么滴滴打人、滴滴代喝、滴滴代嫁等等,哈哈哈。但是,滴滴代驾、滴滴拼车业务真的出现了。滴滴的核心是:根据地理位置(智能手机独特特性)、根据业务大数据和用户画像,智能匹配最合适的打车人和出租车,抽取中间的调度佣金。这本质也是电商+企业服务的混合体。

也就是说,智能调度匹配抽佣金,这个模式,会在中国业务+IT服务的各行各业中,都会形成落地的业务场景。这就是一种经过验证的以技术为本的商业模式。这个模式,非常值得中国企业服务商去探索借鉴思考。

十六、2015:中国互联网金融元年

这一年,在中央的大众创业万众创新的推动下,互联网金融开始热潮。当然,中国电子商务要高速发展,没有金融的支撑也是不能更快更大的发展。

所以这一年,P2P热、众筹热、消费贷热、供应链金融热都起来了。

但更突出的是:微信支付和支付宝支付开始大战。大家纷纷通过各种扫街、发起补贴活动,到处贴二维码,可以扫码支付。现在,就连买菜买鸡蛋夹肉饼,都可以用手机扫码。这种便捷性是全世界最领先的。

十七、2016年:智能元年

这一年,直播热崛起。但是这种直播和过去最早YY的直播还不一样。现在的直播最关键应用了实时美颜技术、虚拟AR技术。

这一年,从支付宝AR找福字、美颜App自带兔子耳朵虚拟表情开始,就发现今年的不一样了。那就是现实和虚拟的实时结合。

所以这一年,也带动了AR、VR设备热。也带动了人工智能技术热,先从人脸识别开始。

直播热从娱乐很快扩展到了电商,从虚拟送礼盈利走向推荐商品带货盈利。这也造就了2016年的微商热。这不同于过去的微商拼命加5000人拼命加群拼命发朋友圈鸡汤发微商广告的模式。这一年的微商都在实时美颜直播技术中统统成为了网红。

直播打赏热(这里也有上一年移动支付大战红包大战的功劳),也渐渐带动了另外一个正经事:知识网红(如罗振宇)+知识付费(如得到)。

这一年,还出现了共享单车大战,最后连颜色都不够用了。这里面最有名的论战就是马化腾和朱啸虎的言战,焦点是谁能笑到最后。马化腾认为是一定要是智能设备,如智能车锁,这显然是技术派的看法。而朱啸虎代表运营派,也就是说:最成熟的产品和消费习惯,最广阔的市场,用资本轰开。现在,朱啸虎的OfO陷入尴尬境地,朱啸虎后来都暗示服了软,显然,智能才是核心。

十八、2017年:新零售元年

2017年说什么热,那必须是新零售。新零售的本质是用智能传感设备、人工智能技术,实现线下数据收集和线上电商是一样的效果。大家切记切记。

虽然说,有人把新零售看做是线下,用正规企业运营方法再重做一次,就如同当年如家他们用资本+企业标准运营管理方法重塑中国快捷酒店业一样。

技术派:无人零售商店、无人货架&货柜、智能购物车、智能称重台、人脸识别进门、人脸识别自动支付

运营派:生鲜、生鲜+餐饮堂食、连锁便利店、中央厨房供应链….

十九、2018年:

2018年,中国互联网金融热已经过去了3年。今年卷土重来的是:区块链。创建X币项目、发币上交易所市,成了主流割韭菜模式。看不清看不清。

在去年直播热、直播技术、直播打赏普及成熟的基础上,快手、抖音短视频热崛起。但是这种短视频又和过去的移动视频热不一样。因为除了技术流畅、打赏付费习惯成熟外,现在抖音又多了附近、朋友、互动。这简直是下一代社交网络的潜力啊。怪不得腾讯今天上半年从收购到打击抖音到内部赛马做了N多短视频App,根源就在于此。

我过去就说过,QQ发源于台式机拨号上网文字时代,微信发源于智能手机4G上网语音时代,那么下一代社交网络工具一定是基于万物互联5G上网视频时代。

从2008年智能手机元年开始算起,今年也已经十年了。智能手机移动互联网时代也要高潮地结束了。今年,小米也要在港交所上市了。

一个时代即将结束(还有2年最后的两个黑洞大碰撞,我猜是腾讯集团和今日头条集团),那么我们在今年,确实应该多静下来思考思考,几个好友坐下来重新回归历史一片空白该想想了、放开脑洞发散性讨论讨论了。

下一代主流硬件是什么?下一代主流OS是什么?

下一代主流社交网络工具是什么?下一代搜索是什么(是视觉识别和语音交互吗)?

下一代内容是什么样子的?比如说新闻、文学、视频、音乐…。

下一代游戏是什么样子的(是ARVR吗)?

下一代电子商务是什么样子的?下一代后端企业服务是什么样子的?

这里边,有你吗?

下一代商业模式的核心要素是什么?除了:流量、资本、技术和数据以及开放平台外,还有什么新的要素?

from:https://mp.weixin.qq.com/s/X195WPlHz6IyMyg-lpc9Yg

应用程序开发: Cordova vs ReactNative vs Xamarin vs DIY

标签: React Xamarin

你还在通过编写本地的iOS或Android代码来创建移动应用程序吗?对于那些平台特定的编程语言和工具、技能集问题、程序有非常具体的需要或者只是无知,或许这才是永远的爱。该是我们重新审视移动应用程序开发、选择合适的工具和框架集的时候了,以使我们的工作有更高的投资回报率(ROI)和更快的开发速度。

我和周围的很多开发者聊过,他们绝大多数都不喜欢用本地iOS(Swift、object C)、android(java)或者Windows(.Net)特定的编程语言和工具开发移动应用程序,因为他们的程序设计目标是多平台。原因在于本地开发需要每个平台对应自己特定的技能集,通常需要更多的开发努力。

几个月前,我们开始使用React Native,必须承认对于应用程序(app)开发来说,它的功能非常强大,使用起来也很愉快。自从Facebook用React native实现了对Android的支持起,我们基本上接受了它。尽管如此,React Native并非独一无二,还有另外一些很棒的选项,比如Xamarin。对于快速移动应用程序开发来说,Xamarin是一种功能最丰富、易于创建和使用的平台。

我在这里不会涉及所有可选的移动应用程序开发平台,只是分别用一个有代表性的平台来说明不同的开发方法,以便让你理解每一种开发方法的概念和方法论。

移动应用程序开发-平台的选择

说起移动应用程序开发,自然界中有许多平台和工具可以使用。在过去的几周里,我对各种开发方法进行了评估,并得出结论,有五种开发方法可供选择,列举如下:

  • 本地开发
  • Cordova :基于混合模式移动应用开发(Hybrid app)
  • 使用React Native进行移动应用程序开发
  • 使用Xamarin进行移动应用程序开发
  • DIY (Do It Yourself)工具:最后但并非最不重要

所有的工具都可以划归到上面提及的某一类中,它们提供了不同的功能集,需要特定的技能集来进行移动应用的设计与开发。在长期的移动应用开发策略中,首先选择正确的工具/平台是非常关键的因素。

选择哪个移动app开发更好?

选择不同的本地代码开发具有他们自己的优势和背后的道理。没有任何一个工具或者方法注定就是赢家,由于它依赖多种因素。在选择一个特定app开发平台或者方法最重要的因素依赖下面的关键点——

  • 个人或者开发团队的技能
  • app独一无二的需求
  • 目标用户划分
  • 个人或者组织的长期策略视野

如果你只是在一个特定平台开发apps,那使用native(swift,objective c 开发ios,java开发android)是最佳选择,因为你可以获得最佳性能、最新的APIs和工作特征。

你只是选择一个平台,那么,不必担心代码的复用。偏离本地主要理由是开发团队的技能,虽然不是唯一的一个。

让我们看看本地开发不同选择的替代方面。

基于Cordova的移动App开发

混合App开发使用纯的JavaScript、HTML和CSS ,它是最容易和最流行的开发方法之一,它在过去的网络开发中处于优势地位。有大量的框架采用了古老的纯的JavaScript和CSS,这些框架可以让你很轻松地进行移动App开发;其中的一些框架包括Ionic, kendo UI和 jQuery Mobile。

当然,你也可以选择不使用已有的框架,而是使用纯净的JavaScript、HTML和CSS,从头开始构建你的App部件。然而,使用像 Ionic、Kendo UI、 jQuery Mobile、 Onesen UI或者其它任何一种建立好的框架都会使你的开发时间以指数方式减少。

你或许想要查看这篇热门文章 – 最好的混合App开发框架

你的App如何访问硬件组成呢?

Cordova该要出场了。它提出了统一的JavaScript API,使用这些API可以访问像摄像头和加速度传感器一类的设备功能,在Android、iOS和Windows这样的几乎所有平台上都有加速度传感器。你一旦准备好App,就可以使用Cordova对其进行编译,Cordova会将App连同特定的JavaScript、CSS和HTML一起打包进平台特定的容器(webview)中。该容器在你的程序和硬件组成之间通过统一的JavaScript API架起了一座桥梁。

你得到的最大好处是只需要开发和维护单一的代码库,还有就是,如果你已经是一名Web开发者,就无需学习任何新技术了。

这里需要注意的关键点是程序运行在webview容器中,而并非运行在硬件本地,这使得它在性能上比原生Android程序或原生iOS程序要差。但是,所有的App并不都需要超级性能,对此你要首先做出权衡和决定。

Cordova遵循Apache许可证,自由且开源,它由Apache软件基金会发布。要阅读更多有关Cordova的内容可访问cordova.apache.org

使用React Native进行移动App开发

对于快速移动程序开发来说,React native相对较新,但却是一种优秀的开发方法,iOS和Android均可以使用。最近已增加了对于Android的支持。React native是来自于Facebook的开源框架,用来开发原生iOS和Android App。

尽管React Native是市场中的新成员,但是在全球范围内许多开发者和组织已经开始使用它进行跨平台移动App的开发,有一些App范例,比如SoundCloud Pulse、 Discovery VR、Facebook Ads Manager、 Bit Wallet、 Squad、Myntra和Running。

React native同样基于JavaScript,但只是纯的JavaScript、HTML5和CSS没有太多帮助,你需要投入一些时间学习更多的东西。你需要理解React,它是facebook为了开发网络程序于2013年发布的框架,React native是React本身的扩展,它们使用了同样的开发理念。

除了React框架,你还需要理解JSX,JSX是对ECMAScript进行了语法扩展的类XML。一旦你对JSX上了手,那么编写React native UI组件将变得绝对轻而易举。你也需要使用Xcode,它是用来构建Android版本App所需的iOS模拟器和命令行工具。另外,掌握程序架构框架的知识将有助于组织并加速App的开发,这些知识比如有Flux和与之相关联的类似Redux和Reflux这样的包。

React Native和Cordova或PhoneGap之间的比较

在Cordova中基于混合程序使用HTML和JavaScript组件开发的UI运行在Android和iOS平台的webview(内嵌在浏览器中)容器中。在React Native中同样如此,UI是用JavaScript react组件(JSX扩展)编写的,只不过每个React native UI组件和iOS以及Android的原生UI组件都是对应的。因此,用JavaScript编写的组件要转换成原生组件。这样我们就拥有了访问底层平台原生组件的JavaScript代码接口。

例如:创建标签-在react native中用TabBarIOS组件实现iOS中的UITabBar,用DrawerLayoutAndroid组件实现Android中的抽屉(Drawer)效果。

上面的例子也说明使用react native在Android和iOS之间的代码重用并非纯粹的100%,但是根据开发内容的不同,能够达到85%-100%这样的目标。

使用react native最大的好处在于仅仅使用JavaScript就可以同时开发iOS和Android版本的App。理念就是-“仅学习一次,就可以编写任何平台,并达到代码重用的最大化”。

更多有关React Native的知识可访问 react native

使用Xamarin进行移动app开发

Xamarin是用于构建原生移动App的另一平台,它是用于构建App的最有用的平台之一。使用Xamarin,可以通过C#语言编写原生Android、iOS、windows和Mac程序。

Xamarin的开发理念和React native基本一样,但是对技能集的要求有了彻底的改变,因为不再使用JavaScript,而是要使用C#和Microsoft工具。代码也不能100%重用,但80%的目标可以很容易达到。

使用Xamarin编写程序不是最容易的,但是可以让你编写出高性能的移动程序。用C#编写代码时,Xamarin编译器将代码编译成iOS、Android或者Windows Phone各自平台的原生包。对于iOS,会将代码直接编译成ARM汇编代码,所以它是纯碎的原生程序。

Xamarin.forms是由Xamarin团队最新推出的又一个功能,使用它开发原生的Android、iOS或Windows程序可以达到100%的代码重用。这些界面的UI控件在运行时会映射成原生控件,因此100%的代码重用是可能的。尽管它没有涵盖全部的原生控件,但已涵盖编写程序时要用到的90%的控件。

Xamarin是Microsoft收养的孩子。Microsoft最近收购了Xamarin,自此以后,Xamarin的用途会进一步增强,更多的功能会比以前增加的更快。

C#开发者可以自如地使用其中一个最高级的IDE-visual studio进行程序开发。Mac用户也可以使用具有相同丰富特性的Xamarin studio进行开发。

了解更多有关Xamarin的信息可以访问xamarin

使用DIY的APP构建工具进行移动APP开发

你自己的工具不够创新或者无法开发新的应用程序,但是,在短期内这些非常有利于从应用市场获取一个app。这些工具封装了大量模板,正在等待在苹果的应用市场或者谷歌play发布。

这些工具大多数是基于云app开发平台,保障你不用担忧要建立你的系统来构建移动应用。你自己的工具提供直观的app接口就可以用来构建app,不用任何先前的开发经验。

你可以选择一个app模板,以你的方式去自定义和配置他,全部使用你自己的设置。个人与小企业使用这些工具来创建移动apps, 并且更加快速推向市场。

UI/UX设计师总是依赖程序员来实现他们梦寐以求的app以推向市场,但是当今时代,UI/UX设计师可以使用拖拽和摆放工具来创建移动apps,向开发者边缘化。图像设计师可以采用app模板来创建和混合出漂亮好看的图形,使得app看起来独一无二(虽然不仅如此)。品牌与品牌之间的联系具体的图形和颜色,使得app独一无二。

在这个节奏快速的世界,当你的目标是创收,那它可能不总是专注于创新和创造,从零开始建立应用程序,使用现有的app模板来订制您的或者您的客户的需求,这样可能会更加高效。

你可能想查看这篇流行的文章-Top 10 DIY mobile app makers.

结论

应用开发和许多平台的选择都有很多的方法论,没有哪个是通用的。

很多开发者就是爱 Java ,并且持续用 Java 开发安卓应用,不认为有什么其他的选项,同样在 Objective-C 的开发者中也这样。不可否认,本地 app 开发带来的最佳性能和流畅体验。

随着像 Ionic,Onsen UI, Intel XDK 和 Sencha Touch 这些的混合框架的出现, Web 开发者变成移动开发者将不会有任何困难。所有这些框架的处理几乎都是与 JavaScript,CSS 和 HTML 相关,并且支持几乎所有的移动平台。

from:https://www.oschina.net/translate/mobile-app-development-cordova-vs-react-native-vs-xamarin

微服务化之缓存的设计

本文章为《互联网高并发微服务化架构实践》系列课程的第五篇

前四篇为:

微服务化的基石——持续集成

微服务的接入层设计与动静资源隔离

微服务化的数据库设计与读写分离

微服务化之无状态化与容器化

在高并发场景下,需要通过缓存来减少数据库的压力,使得大量的访问进来能够命中缓存,只有少量的需要到数据库层。由于缓存基于内存,可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计,缓存的设计时必不可少的一环。

一、为什么要使用缓存

为什么要使用缓存呢?源于人类的一个梦想,就是多快好省的建设社会主义。

多快好省?很多客户都这么要求,但是作为具体做技术的你,当然知道,好就不能快,多就没法省。

可是没办法,客户都这样要求:

这个能不能便宜一点,你咋这么贵呀,你看人家都很便宜的。(您好,这种打折的房间比较靠里,是不能面向大海的)

你们的性能怎么这么差啊,用你这个系统跑的这么慢,你看人家广告中说速度能达到多少多少。(您好,你如果买一个顶配的,我们也是有这种性能的)

你们服务不行啊,你就不能彬彬有礼,穿着整齐,送点水果瓜子啥的?(您好,我们兰州拉面馆没有这项服务,可以去对面的俏江南看一下)

这么贵的菜,一盘就这么一点点,都吃不饱,就不能上一大盘么。(您好,对面的兰州拉面10块钱一大碗)

怎么办呢?劳动人民还是很有智慧的,就是聚焦核心需求,让最最核心的部分享用好和快,而非核心的部门就多和省就可以了。

你可以大部分时间住在公司旁边的出租屋里面,但是出去度假的一个星期,选一个面朝大海,春暖花开的五星级酒店。

你可以大部分时间都挤地铁,挤公交,跋涉2个小时从北五环到南五环,但是有急事的时候,你可以打车,想旅游的时候,可以租车。

你可以大部分时间都吃普通的餐馆,而朋友来了,就去高级饭店里面搓一顿。

在计算机世界也是这样样子的,如图所示。

越是快的设备,存储量越小,越贵,而越是慢的设备,存储量越大,越便宜。

对于一家电商来讲,我们既希望存储越来越多的数据,因为数据将来就是资产,就是财富,只有有了数据,我们才知道用户需要什么,同时又希望当我想访问这些数据的时候,能够快速的得到,双十一拼的就是速度和用户体验,要让用户有流畅的感觉。

所以我们要讲大量的数据都保存下来,放在便宜的存储里面,同时将经常访问的,放在贵的,小的存储里面,当然贵的快的往往比较资源有限,因而不能长时间被某些数据长期霸占,所以要大家轮着用,所以叫缓存,也就是暂时存着。

二、都有哪些类型的缓存

当一个应用刚开始的时候,架构比较简单,往往就是一个Tomcat,后面跟着一个数据库。

简单的应用,并发量不大的时候,当然没有问题。

然而数据库相当于我们应用的中军大帐,是我们整个架构中最最关键的一部分,也是最不能挂,也最不能会被攻破的一部分,因而所有对数据库的访问都需要一道屏障来进行保护,常用的就是缓存。

我们以Tomcat为分界线,之外我们称为接入层,接入层当然应该有缓存,还有CDN,这个在这篇文章中有详细的描述,微服务的接入层设计与动静资源隔离

Tomcat之后,我们称为应用层,应用层也应该有缓存,这是我们这一节讨论的重点。

最简单的方式就是Tomcat里面有一层缓存,常称为本地缓存LocalCache。

这类的缓存常见的有Ehcache和Guava Cache,由于这类缓存在Tomcat本地,因而访问速度是非常快的。

但是本地缓存有个比较大的缺点,就是缓存是放在JVM里面的,会面临Full GC的问题,一旦出现了FullGC,就会对应用的性能和相应时间产生影响,当然也可以尝试jemalloc的分配方式。

还有一种方式,就是在Tomcat和Mysql中间加了一层Cache,我们常称为分布式缓存。

分布式缓存常见的有Memcached和Redis,两者各有优缺点。

Memcached适合做简单的key-value存储,内存使用率比较高,而且由于是多核处理,对于比较大的数据,性能较好。

但是缺点也比较明显,Memcached严格来讲没有集群机制,横向扩展完全靠客户端来实现。另外Memcached无法持久化,一旦挂了数据就都丢失了,如果想实现高可用,也是需要客户端进行双写才可以。

所以可以看出Memcached真的是设计出来,简简单单为了做一个缓存的。

Redis的数据结构就丰富的多了,单线程的处理所有的请求,对于比较大的数据,性能稍微差一点。

Redis提供持久化的功能,包括RDB的全量持久化,或者AOF的增量持久化,从而使得Redis挂了,数据是有机会恢复的。

Redis提供成熟的主备同步,故障切换的功能,从而保证了高可用性。

所以很多地方管Redis称为内存数据库,因为他的一些特性已经有了数据库的影子。

这也是很多人愿意用Redis的原因,集合了缓存和数据库的优势,但是往往会滥用这些优势,从而忽略了架构层面的设计,使得Redis集群有很大的风险。

很多情况下,会将Redis当做数据库使用,开启持久化和主备同步机制,以为就可以高枕无忧了。

然而Redis的持久化机制,全量持久化则往往需要额外较大的内存,而在高并发场景下,内存本来就很紧张,如果造成swap,就会影响性能。增量持久化也涉及到写磁盘和fsync,也是会拖慢处理的速度,在平时还好,如果高并发场景下,仍然会影响吞吐量。

所以在架构设计角度,缓存就是缓存,要意识到数据会随时丢失的,要意识到缓存的存着的目的是拦截到数据库的请求。如果为了保证缓存的数据不丢失,从而影响了缓存的吞吐量,甚至稳定性,让缓存响应不过来,甚至挂掉,所有的请求击穿到数据库,就是更加严重的事情了。

如果非常需要进行持久化,可以考虑使用levelDB此类的,对于随机写入性能较好的key-value持久化存储,这样只有部分的确需要持久化的数据,才进行持久化,而非无论什么数据,通通往Redis里面扔,同时统一开启了持久化。

三、基于缓存的架构设计要点

所以基于缓存的设计:

1、多层次

这样某一层的缓存挂了,还有另一层可以撑着,等待缓存的修复,例如分布式缓存因为某种原因挂了,因为持久化的原因,同步机制的原因,内存过大的原因等,修复需要一段时间,在这段时间内,至少本地缓存可以抗一阵,不至于一下子就击穿数据库。而且对于特别特别热的数据,热到导致集中式的缓存处理不过来,网卡也被打满的情况,由于本地缓存不需要远程调用,也是分布在应用层的,可以缓解这种问题。

2、分场景

到底要解决什么问题,可以选择不同的缓存。是要存储大的无格式的数据,还是要存储小的有格式的数据,还是要存储一定需要持久化的数据。具体的场景下一节详细谈。

3、要分片

使得每一个缓存实例都不大,但是实例数目比较多,这样一方面可以实现负载均衡,防止单个实例称为瓶颈或者热点,另一方面如果一个实例挂了,影响面会小很多,高可用性大大增强。分片的机制可以在客户端实现,可以使用中间件实现,也可以使用Redis的Cluster的方式,分片的算法往往都是哈希取模,或者一致性哈希。

四、缓存的使用场景

当你的应用扛不住,知道要使用缓存了,应该怎么做呢?

场景1:和数据库中的数据结构保持一致,原样缓存

这种场景是最常见的场景,也是很多架构使用缓存的适合,最先涉及到的场景。

基本就是数据库里面啥样,我缓存也啥样,数据库里面有商品信息,缓存里面也放商品信息,唯一不同的是,数据库里面是全量的商品信息,缓存里面是最热的商品信息。

每当应用要查询商品信息的时候,先查缓存,缓存没有就查数据库,查出来的结果放入缓存,从而下次就查到了。

这个是缓存最最经典的更新流程。这种方式简单,直观,很多缓存的库都默认支持这种方式。

场景2:列表排序分页场景的缓存

有时候我们需要获得一些列表数据,并对这些数据进行排序和分页。

例如我们想获取点赞最多的评论,或者最新的评论,然后列出来,一页一页的翻下去。

在这种情况下,缓存里面的数据结构和数据库里面完全不一样。

如果完全使用数据库进行实现,则按照某种条件将所有的行查询出来,然后按照某个字段进行排序,然后进行分页,一页一页的展示。

但是当数据量比较大的时候,这种方式往往成为瓶颈,首先涉及的数据库行数比较多,而且排序也是个很慢的活,尽管可能有索引,分页也是翻页到最后,越是慢。

在缓存里面,就没必要每行一个key了,而是可以使用Redis的列表方式进行存储,当然列表的长短是有限制的,肯定放不下数据库里面这么多,但是大家会发现其实对于所有的列表,用户往往没有耐心看个十页八页的,例如百度上搜个东西,也是有排序和分页的,但是你每次都往后翻了吗,每页就十条,就算是十页,或者一百页,也就一千条数据,如果保持ID的话,完全放的下。

如果已经排好序,放在Redis里面,那取出列表,翻页就非常快了。

可以后台有一个线程,异步的初始化和刷新缓存,在缓存里面保存一个时间戳,当有更新的时候,刷新时间戳,异步任务发现时间戳改变了,就刷新缓存。

场景3:计数缓存

计数对于数据库来讲,是一个非常繁重的工作,需要查询大量的行,最后得出计数的结论,当数据改变的时候,需要重新刷一遍,非常影响性能。

因此可以有一个计数服务,后端是一个缓存,将计数作为结果放在缓存里面,当数据有改变的时候,调用计数服务增加或者减少计数,而非通过异步数据库count来更新缓存。

计数服务可以使用Redis进行单个计数,或者hash表进行批量计数

场景4:重构维度缓存

有时候数据库里面保持的数据的维度是为了写入方便,而非为了查询方便的,然而同时查询过程,也需要处理高并发,因而需要为了查询方便,将数据重新以另一个维度存储一遍,或者说将多给数据库的内容聚合一下,再存储一遍,从而不用每次查询的时候都重新聚合,如果还是放在数据库,比较难维护,放在缓存就好一些。

例如一个商品的所有的帖子和帖子的用户,以及一个用户发表过的所有的帖子就是属于两个维度。

这需要写入一个维度的时候,同时异步通知,更新缓存中的另一个维度。

在这种场景下,数据量相对比较大,因而单纯用内存缓存memcached或者redis难以支撑,往往会选择使用levelDB进行存储,如果levelDB的性能跟不上,可以考虑在levelDB之前,再来一层memcached。

场景5:较大的详情内容数据缓存

对于评论的详情,或者帖子的详细内容,属于非结构化的,而且内容比较大,因而使用memcached比较好。

五、缓存三大矛盾问题

1、缓存实时性和一致性问题:当有了写入后咋办?

虽然使用了缓存,大家心里都有一个预期,就是实时性和一致性得不到完全的保证,毕竟数据保存了多份,数据库一份,缓存中一份,当数据库中因写入而产生了新的数据,往往缓存是不会和数据库操作放在一个事务里面的,如何将新的数据更新到缓存里面,什么时候更新到缓存里面,不同的策略不一样。

从用户体验角度,当然是越实时越好,用户体验越流畅,完全从这个角度出发,就应该有了写入,马上废弃缓存,触发一次数据库的读取,从而更新缓存。但是这和第三个问题,高并发就矛盾了,如果所有的都实时从数据库里面读取,高并发场景下,数据库往往受不了。

2、缓存的穿透问题:当没有读到咋办?

为什么会出现缓存读取不到的情况呢?

第一:可能读取的是冷数据,原来从来没有访问过,所以需要到数据库里面查询一下,然后放入缓存,再返回给客户。

第二:可能数据因为有了写入,被实时的从缓存中删除了,就如第一个问题中描述的那样,为了保证实时性,当数据库中的数据更新了之后,马上删除缓存中的数据,导致这个时候的读取读不到,需要到数据库里面查询后,放入缓存,再返回给客户。

第三:可能是缓存实效了,每个缓存数据都会有实效时间,过了一段时间没有被访问,就会失效,这个时候数据就访问不到了,需要访问数据库后,再放入缓存。

第四:数据被换出,由于缓存内存是有限的,当使用快满了的时候,就会使用类似LRU策略,将不经常使用的数据换出,所以也要访问数据库。

第五:后端确实也没有,应用访问缓存没有,于是查询数据库,结果数据库里面也没有,只好返回客户为空,但是尴尬的是,每次出现这种情况的时候,都会面临着一次数据库的访问,纯属浪费资源,常用的方法是,讲这个key对应的结果为空的事实也进行缓存,这样缓存可以命中,但是命中后告诉客户端没有,减少了数据库的压力。

无论哪种原因导致的读取缓存读不到的情况,该怎么办?是个策略问题。

一种是同步访问数据库后,放入缓存,再返回给客户,这样实时性最好,但是给数据库的压力也最大。

另一种方式就是异步的访问数据库,暂且返回客户一个fallback值,然后同时触发一个异步更新,这样下次就有了,这样数据库压力小很多,但是用户就访问不到实时的数据了。

3、缓存对数据库高并发访问:都来访问数据库咋办?

我们本来使用缓存,是来拦截直接访问数据库请求的,从而保证数据库大本营永远处于健康的状态。但是如果一遇到不命中,就访问数据库的话,平时没有什么问题,但是大促情况下,数据库是受不了的。

一种情况是多个客户端,并发状态下,都不命中了,于是并发的都来访问数据库,其实只需要访问一次就好,这种情况可以通过加锁,只有一个到后端来实现。

另外就是即便采取了上述的策略,依然并发量非常大,后端的数据库依然受不了,则需要通过降低实时性,将缓存拦在数据库前面,暂且撑住,来解决。

六、解决缓存三大矛盾的刷新策略

1、实时策略

所谓的实时策略,是平时缓存使用的最常用的策略,也是保持实时性最好的策略。

读取的过程,应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。如果命中,应用程序从cache中取数据,取到后返回。

写入的过程,把数据存到数据库中,成功后,再让缓存失效,失效后下次读取的时候,会被写入缓存。那为什么不直接写缓存呢?因为如果两个线程同时更新数据库,一个将数据库改为10,一个将数据库改为20,数据库有自己的事务机制,可以保证如果20是后提交的,数据库里面改为20,但是回过头来写入缓存的时候就没有事务了,如果改为20的线程先更新缓存,改为10的线程后更新缓存,于是就会长时间出现缓存中是10,但是数据库中是20的现象。

这种方式实时性好,用户体验好,是默认应该使用的策略。

2、异步策略

所谓异步策略,就是当读取的时候读不到的时候,不直接访问数据库,而是返回一个fallback数据,然后往消息队列里面放入一个数据加载的事件,在背后有一个任务,收到事件后,会异步的读取数据库,由于有队列的作用,可以实现消峰,缓冲对数据库的访问,甚至可以将多个队列中的任务合并请求,合并更新缓存,提高了效率。

当更新的时候,异步策略总是先更新数据库和缓存中的一个,然后异步的更新另一个。

一是先更新数据库,然后异步更新缓存。当数据库更新后,同样生成一个异步消息,放入消息队列中,等待背后的任务通过消息进行缓存更新,同样可以实现消峰和任务合并。缺点就是实时性比较差,估计要过一段时间才能看到更新,好处是数据持久性可以得到保证。

一是先更新缓存,然后异步更新数据库。这种方式读取和写入都用缓存,将缓存完全挡在了数据库的前面,把缓存当成了数据库在用。所以一般会使用有持久化机制和主备的redis,但是仍然不能保证缓存不丢数据,所以这种情况适用于并发量大,但是数据没有那么关键的情况,好处是实时性好。

在实时策略扛不住大促的时候,可以根据场景,切换到上面的两种模式的一个,算是降级策略。

3、定时策略

如果并发量实在太大,数据量也大的情况,异步都难以满足,可以降级为定时刷新的策略,这种情况下,应用只访问缓存,不访问数据库,更新频率也不高,而且用户要求也不高,例如详情,评论等。

这种情况下,由于数据量比较大,建议将一整块数据拆分成几部分进行缓存,而且区分更新频繁的和不频繁的,这样不用每次更新的时候,所有的都更新,只更新一部分。并且缓存的时候,可以进行数据的预整合,因为实时性不高,读取预整合的数据更快。

有关缓存就说到这里,下一节讲分布式事务。

from:https://mp.weixin.qq.com/s/-9wHpKGf7aJSbtShpCcoVg