分类
未分类

16张图带你如何从0到1构建一个稳定、高性能的Redis集群?

点击上方蓝色“石杉的架构笔记”,选择“设为星标”

回复“PDF”获取独家整理的学习资料!

长按扫描上方二维码一元购买


阅读本文大约需要 13 分钟。

现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Redis 时,有没有思考过,Redis 到底是如何稳定、高性能地提供服务的?

你也可以尝试回答一下以下这些问题:

  • 我使用 Redis 的场景很简单,只使用单机版 Redis 会有什么问题吗?
  • 我的 Redis 故障宕机了,数据丢失了怎么办?如何能保证我的业务应用不受影响?
  • 为什么需要主从集群?它有什么优势?
  • 什么是分片集群?我真的需要分片集群吗?

如果你对 Redis 已经有些了解,肯定也听说过数据持久化、主从复制、哨兵这些概念,它们之间又有什么区别和联系呢?

如果你存在这样的疑惑,这篇文章,我会从 0 到 1,再从 1 到 N,带你一步步构建出一个稳定、高性能的 Redis 集群。

在这个过程中,你可以了解到 Redis 为了做到稳定、高性能,都采取了哪些优化方案,以及为什么要这么做?

掌握了这些原理,这样平时你在使用 Redis 时,就能够做到「游刃有余」。

这篇文章干货很多,希望你可以耐心读完。

从最简单的开始:单机版 Redis

首先,我们从最简单的场景开始。

假设现在你有一个业务应用,需要引入 Redis 来提高应用的性能,此时你可以选择部署一个单机版的 Redis 来使用,就像这样:

这个架构非常简单,你的业务应用可以把 Redis 当做缓存来使用,从 MySQL 中查询数据,然后写入到 Redis 中,之后业务应用再从 Redis 中读取这些数据,由于 Redis 的数据都存储在内存中,所以这个速度飞快。

如果你的业务体量并不大,那这样的架构模型基本可以满足你的需求。是不是很简单?

随着时间的推移,你的业务体量逐渐发展起来了,Redis 中存储的数据也越来越多,此时你的业务应用对 Redis 的依赖也越来越重。

但是,突然有一天,你的 Redis 因为某些原因宕机了,这时你的所有业务流量,都会打到后端 MySQL 上,这会导致你的 MySQL 压力剧增,严重的话甚至会压垮 MySQL。

这时你应该怎么办?

我猜你的方案肯定是,赶紧重启 Redis,让它可以继续提供服务。

但是,因为之前 Redis 中的数据都在内存中,尽管你现在把 Redis 重启了,之前的数据也都丢失了。重启后的 Redis 虽然可以正常工作,但是由于 Redis 中没有任何数据,业务流量还是都会打到后端 MySQL 上,MySQL 的压力还是很大。

这可怎么办?你陷入了沉思。

有没有什么好的办法解决这个问题?

既然 Redis 只把数据存储在内存中,那是否可以把这些数据也写一份到磁盘上呢?

如果采用这种方式,当 Redis 重启时,我们把磁盘中的数据快速恢复到内存中,这样它就可以继续正常提供服务了。

是的,这是一个很好的解决方案,这个把内存数据写到磁盘上的过程,就是「数据持久化」。

数据持久化:有备无患

现在,你设想的 Redis 数据持久化是这样的:

但是,数据持久化具体应该怎么做呢?

我猜你最容易想到的一个方案是,Redis 每一次执行写操作,除了写内存之外,同时也写一份到磁盘上,就像这样:

没错,这是最简单直接的方案。

但仔细想一下,这个方案有个问题:客户端的每次写操作,既需要写内存,又需要写磁盘,而写磁盘的耗时相比于写内存来说,肯定要慢很多!这势必会影响到 Redis 的性能。

如何规避这个问题?

我们可以这样优化:Redis 写内存由主线程来做,写内存完成后就给客户端返回结果,然后 Redis 用另一个线程去写磁盘,这样就可以避免主线程写磁盘对性能的影响。

这确实是一个好方案。除此之外,我们可以换个角度,思考一下还有什么方式可以持久化数据?

这时你就要结合 Redis 的使用场景来考虑了。

回忆一下,我们在使用 Redis 时,通常把它用作什么场景?

是的,缓存。

把 Redis 当做缓存来用,意味着尽管 Redis 中没有保存全量数据,对于不在缓存中的数据,我们的业务应用依旧可以通过查询后端数据库得到结果,只不过查询后端数据的速度会慢一点而已,但对业务结果其实是没有影响的。

基于这个特点,我们的 Redis 数据持久化还可以用「数据快照」的方式来做。

那什么是数据快照呢?

简单来讲,你可以这么理解:

  1. 你把 Redis 想象成一个水杯,向 Redis 写入数据,就相当于往这个杯子里倒水
  2. 此时你拿一个相机给这个水杯拍一张照片,拍照的这一瞬间,照片中记录到这个水杯中水的容量,就是水杯的数据快照

也就是说,Redis 的数据快照,是记录某一时刻下 Redis 中的数据,然后只需要把这个数据快照写到磁盘上就可以了。

它的优势在于,只在需要持久化时,把数据「一次性」写入磁盘,其它时间都不需要操作磁盘。

基于这个方案,我们可以定时给 Redis 做数据快照,把数据持久化到磁盘上。

其实,上面说的这些持久化方案,就是 Redis 的「RDB」和「AOF」:

  • RDB:只持久化某一时刻的数据快照到磁盘上(创建一个子进程来做)
  • AOF:每一次写操作都持久到磁盘(主线程写内存,根据策略可以配置由主线程还是子线程进行数据持久化)

它们的区别除了上面讲到的,还有以下特点:

  1. RDB 采用二进制 + 数据压缩的方式写磁盘,这样文件体积小,数据恢复速度也快
  2. AOF 记录的是每一次写命令,数据最全,但文件体积大,数据恢复速度慢

如果让你来选择持久化方案,你可以这样选择:

  1. 如果你的业务对于数据丢失不敏感,采用 RDB 方案持久化数据
  2. 如果你的业务对数据完整性要求比较高,采用 AOF 方案持久化数据

假设你的业务对 Redis 数据完整性要求比较高,选择了 AOF 方案,那此时你又会遇到这些问题:

  1. AOF 记录每一次写操作,随着时间增长,AOF 文件体积会越来越大
  2. 这么大的 AOF 文件,在数据恢复时变得非常慢

这怎么办?数据完整性要求变高了,恢复数据也变困难了?有没有什么方法,可以缩小文件体积?提升恢复速度呢?

我们继续来分析 AOF 的特点。

由于 AOF 文件中记录的都是每一次写操作,但对于同一个 key 可能会发生多次修改,我们只保留最后一次被修改的值,是不是也可以?

是的,这就是我们经常听到的「AOF rewrite」,你也可以把它理解为 AOF 「瘦身」。

我们可以对 AOF 文件定时 rewrite,避免这个文件体积持续膨胀,这样在恢复时就可以缩短恢复时间了。

再进一步思考一下,还有没有办法继续缩小 AOF 文件?

回顾一下我们前面讲到的,RDB 和 AOF 各自的特点:

  1. RDB 以二进制 + 数据压缩方式存储,文件体积小
  2. AOF 记录每一次写命令,数据最全

我们可否利用它们各自的优势呢?

当然可以,这就是 Redis 的「混合持久化」。

具体来说,当 AOF rewrite 时,Redis 先以 RDB 格式在 AOF 文件中写入一个数据快照,再把在这期间产生的每一个写命令,追加到 AOF 文件中。因为 RDB 是二进制压缩写入的,这样 AOF 文件体积就变得更小了。

此时,你在使用 AOF 文件恢复数据时,这个恢复时间就会更短了!

Redis 4.0 以上版本才支持混合持久化。

这么一番优化,你的 Redis 再也不用担心实例宕机了,当发生宕机时,你就可以用持久化文件快速恢复 Redis 中的数据。

但这样就没问题了吗?

仔细想一下,虽然我们已经把持久化的文件优化到最小了,但在恢复数据时依旧是需要时间的,在这期间你的业务应用还是会受到影响,这怎么办?

我们来分析有没有更好的方案。

一个实例宕机,只能用恢复数据来解决,那我们是否可以部署多个 Redis 实例,然后让这些实例数据保持实时同步,这样当一个实例宕机时,我们在剩下的实例中选择一个继续提供服务就好了。

没错,这个方案就是接下来要讲的「主从复制:多副本」。

主从复制:多副本

此时,你可以部署多个 Redis 实例,架构模型就变成了这样:

我们这里把实时读写的节点叫做 master,另一个实时同步数据的节点叫做 slave。

采用多副本的方案,它的优势是:

  1. 缩短不可用时间:master 发生宕机,我们可以手动把 slave 提升为 master 继续提供服务
  2. 提升读性能:让 slave 分担一部分读请求,提升应用的整体性能

这个方案不错,不仅节省了数据恢复的时间,还能提升性能,那它有什么问题吗?

你可以思考一下。

其实,它的问题在于:当 master 宕机时,我们需要「手动」把 slave 提升为 master,这个过程也是需要花费时间的。

虽然比恢复数据要快得多,但还是需要人工介入处理。一旦需要人工介入,就必须要算上人的反应时间、操作时间,所以,在这期间你的业务应用依旧会受到影响。

怎么解决这个问题?我们是否可以把这个切换的过程,变成自动化呢?

对于这种情况,我们需要一个「故障自动切换」机制,这就是我们经常听到的「哨兵」所具备的能力。

哨兵:故障自动切换

现在,我们可以引入一个「观察者」,让这个观察者去实时监测 master 的健康状态,这个观察者就是「哨兵」。

具体如何做?

  1. 哨兵每间隔一段时间,询问 master 是否正常
  2. master 正常回复,表示状态正常,回复超时表示异常
  3. 哨兵发现异常,发起主从切换

有了这个方案,就不需要人去介入处理了,一切就变得自动化了,是不是很爽?

但这里还有一个问题,如果 master 状态正常,但这个哨兵在询问 master 时,它们之间的网络发生了问题,那这个哨兵可能会误判。

这个问题怎么解决?

答案是,我们可以部署多个哨兵,让它们分布在不同的机器上,它们一起监测 master 的状态,流程就变成了这样:

  1. 多个哨兵每间隔一段时间,询问 master 是否正常
  2. master 正常回复,表示状态正常,回复超时表示异常
  3. 一旦有一个哨兵判定 master 异常(不管是否是网络问题),就询问其它哨兵,如果多个哨兵(设置一个阈值)都认为 master 异常了,这才判定 master 确实发生了故障
  4. 多个哨兵经过协商后,判定 master 故障,则发起主从切换

所以,我们用多个哨兵互相协商来判定 master 的状态,这样一来,就可以大大降低误判的概率。

哨兵协商判定 master 异常后,这里还有一个问题:由哪个哨兵来发起主从切换呢?

答案是,选出一个哨兵「领导者」,由这个领导者进行主从切换。

问题又来了,这个领导者怎么选?

想象一下,在现实生活中,选举是怎么做的?

是的,投票。

在选举哨兵领导者时,我们可以制定这样一个选举规则:

  1. 每个哨兵都询问其它哨兵,请求对方为自己投票
  2. 每个哨兵只投票给第一个请求投票的哨兵,且只能投票一次
  3. 首先拿到超过半数投票的哨兵,当选为领导者,发起主从切换

其实,这个选举的过程就是我们经常听到的:分布式系统领域中的「共识算法」。

什么是共识算法?

我们在多个机器部署哨兵,它们需要共同协作完成一项任务,所以它们就组成了一个「分布式系统」。

在分布式系统领域,多个节点如何就一个问题达成共识的算法,就叫共识算法。

在这个场景下,多个哨兵共同协商,选举出一个都认可的领导者,就是使用共识算法完成的。

这个算法还规定节点的数量必须是奇数个,这样可以保证系统中即使有节点发生了故障,剩余超过「半数」的节点状态正常,依旧可以提供正确的结果,也就是说,这个算法还兼容了存在故障节点的情况。

共识算法在分布式系统领域有很多,例如 Paxos、Raft,哨兵选举领导者这个场景,使用的是 Raft 共识算法,因为它足够简单,且易于实现。

现在,我们用多个哨兵共同监测 Redis 的状态,这样一来,就可以避免误判的问题了,架构模型就变成了这样:

好了,到这里我们先小结一下。

你的 Redis 从最简单的单机版,经过数据持久化、主从多副本、哨兵集群,这一路优化下来,你的 Redis 不管是性能还是稳定性,都越来越高,就算节点发生故障,也不用担心了。

你的 Redis 以这样的架构模式部署,基本上就可以稳定运行很长时间了。

随着时间的发展,你的业务体量开始迎来了爆炸性增长,此时你的架构模型,还能够承担这么大的流量吗?

我们一起来分析一下:

  1. 稳定性:Redis 故障宕机,我们有哨兵 + 副本,可以自动完成主从切换
  2. 性能:读请求量增长,我们可以再部署多个 slave,读写分离,分担读压力
  3. 性能:写请求量增长,但我们只有一个 master 实例,这个实例达到瓶颈怎么办?

看到了么,当你的写请求量越来越大时,一个 master 实例可能就无法承担这么大的写流量了。

要想完美解决这个问题,此时你就需要考虑使用「分片集群」了。

分片集群:横向扩展

什么是「分片集群」?

简单来讲,一个实例扛不住写压力,那我们是否可以部署多个实例,然后把这些实例按照一定规则组织起来,把它们当成一个整体,对外提供服务,这样不就可以解决集中写一个实例的瓶颈问题吗?

所以,现在的架构模型就变成了这样:

现在问题又来了,这么多实例如何组织呢?

我们制定规则如下:

  1. 每个节点各自存储一部分数据,所有节点数据之和才是全量数据
  2. 制定一个路由规则,对于不同的 key,把它路由到固定一个实例上进行读写

而分片集群根据路由规则所在位置的不同,还可以分为两大类:

  1. 客户端分片
  2. 服务端分片

客户端分片指的是,key 的路由规则放在客户端来做,就是下面这样:

这个方案的缺点是,客户端需要维护这个路由规则,也就是说,你需要把路由规则写到你的业务代码中。

如何做到不把路由规则耦合在业务代码中呢?

你可以这样优化,把这个路由规则封装成一个模块,当需要使用时,集成这个模块就可以了。

这就是 Redis Cluster 的采用的方案。

Redis Cluster 内置了哨兵逻辑,无需再部署哨兵。

当你使用 Redis Cluster 时,你的业务应用需要使用配套的 Redis SDK,这个 SDK 内就集成好了路由规则,不需要你自己编写了。

再来看服务端分片。

这种方案指的是,路由规则不放在客户端来做,而是在客户端和服务端之间增加一个「中间代理层」,这个代理就是我们经常听到的 Proxy。

而数据的路由规则,就放在这个 Proxy 层来维护。

这样一来,你就无需关心服务端有多少个 Redis 节点了,只需要和这个 Proxy 交互即可。

Proxy 会把你的请求根据路由规则,转发到对应的 Redis 节点上,而且,当集群实例不足以支撑更大的流量请求时,还可以横向扩容,添加新的 Redis 实例提升性能,这一切对于你的客户端来说,都是透明无感知的。

业界开源的 Redis 分片集群方案,例如 Twemproxy、Codis 就是采用的这种方案。

分片集群在数据扩容时,还涉及到了很多细节,这块内容不是本文章重点,所以暂不详述。

至此,当你使用分片集群后,对于未来更大的流量压力,都可以从容面对了!

总结

好了,我们来总结一下,我们是如何一步步构建一个稳定、高性能的 Redis 集群的。

首先,在使用最简单的单机版 Redis 时,我们发现当 Redis 故障宕机后,数据无法恢复的问题,因此我们想到了「数据持久化」,把内存中的数据也持久化到磁盘上一份,这样 Redis 重启后就可以从磁盘上快速恢复数据。

在进行数据持久化时,我们又面临如何更高效地将数据持久化到磁盘的问题。之后我们发现 Redis 提供了 RDB 和 AOF 两种方案,分别对应了数据快照和实时的命令记录。当我们对数据完整性要求不高时,可以选择 RDB 持久化方案。如果对于数据完整性要求较高,那么可以选择 AOF 持久化方案。

但是我们又发现,AOF 文件体积会随着时间增长变得越来越大,此时我们想到的优化方案是,使用 AOF rewrite 的方式对其进行瘦身,减小文件体积,再后来,我们发现可以结合 RDB 和 AOF 各自的优势,在 AOF rewrite 时使用两者结合的「混合持久化」方式,又进一步减小了 AOF 文件体积。

之后,我们发现尽管可以通过数据恢复的方式还原数据,但恢复数据也是需要花费时间的,这意味着业务应用还是会受到影响。我们进一步优化,采用「多副本」的方案,让多个实例保持实时同步,当一个实例故障时,可以手动把其它实例提升上来继续提供服务。

但是这样也有问题,手动提升实例上来,需要人工介入,人工介入操作也需要时间,我们开始想办法把这个流程变得自动化,所以我们又引入了「哨兵」集群,哨兵集群通过互相协商的方式,发现故障节点,并可以自动完成切换,这样就大幅降低了对业务应用的影响。

最后,我们把关注点聚焦在如何支撑更大的写流量上,所以,我们又引入了「分片集群」来解决这个问题,让多个 Redis 实例分摊写压力,未来面对更大的流量,我们还可以添加新的实例,横向扩展,进一步提升集群的性能。

至此,我们的 Redis 集群才得以长期稳定、高性能的为我们的业务提供服务。

这里我画了一个思维导图,方便你更好地去理解它们之间的关系,以及演化的过程。

后记

看到这里,我想你对如何构建一个稳定、高性能的 Redis 集群问题时,应该会有自己的见解了。

其实,这篇文章所讲的优化思路,围绕的主题就是「架构设计」的核心思想:

  • 高性能:读写分离、分片集群
  • 高可用:数据持久化、多副本、故障自动切换
  • 易扩展:分片集群、横向扩展

当我们讲到哨兵集群、分片集群时,这还涉及到了「分布式系统」相关的知识:

  • 分布式共识:哨兵领导者选举
  • 负载均衡:分片集群数据分片、数据路由

当然,除了 Redis 之外,对于构建任何一个数据集群,你都可以沿用这个思路去思考、去优化,看看它们到底是如何做的。

例如当你在使用 MySQL 时,你可以思考一下 MySQL 与 Redis 有哪些不同?MySQL 为了做到高性能、高可用,又是如何做的?其实思路都是类似的。

我们现在到处可见分布式系统、数据集群,我希望通过这篇文章,你可以理解这些软件是如何一步步演化过来的,在演化过程中,它们遇到了哪些问题,为了解决这些问题,这些软件的设计者设计了怎样的方案,做了哪些取舍?

你只有了解了其中的原理,掌握了分析问题、解决问题的能力,这样在以后的开发过程中,或是学习其它优秀软件时,就能快速地找到「重点」,在最短的时间掌握它,并能在实际应用中发挥它们的优势。

其实这个思考过程,也是做「架构设计」的思路。在做软件架构设计时,你面临的场景就是发现问题、分析问题、解决问题,一步步去演化、升级你的架构,最后在性能、可靠性方面达到一个平衡。虽然各种软件层出不穷,但架构设计的思想不会变,我希望你真正吸收的是这些思想,这样才可以做到以不变应万变。


分类
未分类

揭秘开源商业的底层系统:我们为什么看好开源商业?

GGV有话说:


《GGV中美企服20年采访札记》系GGV过去20年中,在企业服务行业大浪淘金后的成果和收获,通过GGV投资人与企业创始人或高管的对谈,呈现其成功背后的商业逻辑与格局。


本系列共15篇章,聚焦云基础设施、企业软件消费化以及电商服务三大板块。每一篇都回顾了企业生根发芽的发展进程,也展示出企业破土而出的精彩时刻;翻阅历史的同时,思考当下的步伐,为各领域致力于开拓创新的创业者和试图改变世界的开荒人提供一份宝贵的创业启示录。


《GGV中美企服20年采访札记》的第四篇,我们将和你讲述我们为什么看好开源商业?



作者:凛

编辑:张颖



2015年,PingCAP 创始人兼 CEO刘奇、PingCAP 联合创始人兼 CTO黄东旭、PingCAP 联合创始人兼CFO崔秋三人创办了PingCAP,主打产品是分布式关系型数据库产品TiDB。在他们的商业版图里,“开源”(Open-Source)极其重要,TiDB的发起、完善等各环节均依托于开源。


PingCAP创始团队成员:黄东旭(PingCAP 联合创始人兼 CTO)、刘奇(PingCAP 创始人兼 CEO)、崔秋(PingCAP 联合创始人兼CFO)


这使PingCAP成为了当年中国极其少见的“出生即开源”并以创业者身份运营的企业之一,它的源代码从始至终都可供任何程序员查看和使用。在全球最大开源开发者社区GitHub上,TiDB共计获得27000+的Star,集合了超过1200位开源代码贡献者,是基础架构领域的明星开源项目。


虽然在程序员群体里口碑爆棚,但对于PingCAP是否能成为一家伟大的企业,业界仍在持续观察,在很多人眼中,这些“开源英雄”能否成功,还要看他们在商业化的成就。


开源的商业化从来都不是一件容易的事情。创办3年后,PingCAP的商业化进程开始逐渐加速。在CEO刘奇的介绍中,截至2020年底,它拥有超过1500个客户,其中付费客户超过百家,中国客户最高客单价规模为百万人民币,尤以中国银行、中国人寿、国泰君安、陆金所等金融企业为主要付费客户。2020年PingCAP完成了2.7亿美元的D轮融资,从融资阶段到额度,都是中国创办的开源产品之最。


GGV纪源资本管理合伙人符绩勋认为,中国公有云化现在进入到0到1的成长阶段,这意味着企业互联网和SaaS服务的崛起。SaaS公司现在越来越多在强调SaaS属性和功能,真正做到了软件即服务。中国整体已经在往积极的方向去努力,我们也看到一大批企业服务公司业务的增长在加快,其中更包括开源产品的进化和迭代。


作为PingCAP的投资机构,GGV纪源资本一直是开源产品的坚定支持者。在海外,GGV投资了全球最顶尖的云公司之一HashiCorp,它的开源软件每年下载量接近8000万,全球500强企业里有100家以上为其客户,最近一轮的估值高达51亿美元;GGV也投资了人工智能和机器学习框架开发商Streamlit,在程序员群体中熟知的API自动化服务Kong,还有总部位于柏林的开源神经搜索初创公司Jina AI。



而在中国,除PingCAP之外,GGV纪源资本企业服务团队分别投资了2014年开始正式商业化运作的RT-Thread以及2019年正式开源的涛思数据。


如果说软件正在吞噬世界,那么开源则正在改写整个软件界。

 

 

PingCAP走过的路:

“那帮理想主义者还没饿死”


当一款产品在C端迅速走红或出圈,随后带来的最大风险是什么?


在拥有14亿人口的中国市场,潜在的最大风险其实是数据库宕机


数据库作为快速成长企业当中最容易滋生痛点的基础设施,在数据暴涨或难以预知数据爆发节点的情况下,一旦数据库出现问题,就如同飞机在飞行过程中不得不更换引擎。


PingCAP团队5年前创办时预测:大数据驱动下,全球数据量过载将是必然趋势,单机MySQL数据库难以满足企业要求,更多企业将选择一款云端的弹性化数据库。这成为了PingCAP创立的初衷:PingCAP立志为这些快速成长的企业做好云端的数据库服务。


而此时,数据库市场还是Oracle等巨头的天下,做数据库研发的创业公司凤毛麟角,用PingCAP投资方、GGV纪源资本执行董事吴陈尧的评价来概括:“想攀登珠峰的人并不多”。



PingCAP海外的支持者分布图


更有意思的是,从创办第一天起,PingCAP就公开了源代码,PingCAP CEO刘奇介绍,所有贡献者都可以提交代码修改,并有可能改变PingCAP的主干代码,这些代码修改形成一个大循环,迅速更新和完善数据库性能。


这也是PingCAP另一个颇为“另类”的决定:开源。


在开源社区这个“委员会”之中,任何企业的程序员都能成为开源社区的贡献者,而这些企业就像派驻了一位代表加入这个“委员会”,他们的意见一定程度上代表了自己所在企业的思考与需求,他们的修改造就了PingCAP的迭代升级。


2015年的互联网行业,举起开源这杆大旗的人并不多,PingCAP为此花费了大量精力,主办了以交流国内外基础架构技术为主题的InfraMeetup,如今算下来,总计举办次数已经超过130期。


在创业者后辈的眼中,PingCAP的成功是有自己的独特策略和打法的。这套策略并不比别人高深多少,也并非像电影里的绝世高手突然机缘巧合收获了一份武功秘籍,而是来源于坚持不懈、源源不断地在几件重要的事情上倾注力量:


比如坚持常年在一线苦心研究技术,比如坚持举办开源技术交流论坛和线下活动,并把自己的钻研所得分享出去,毫不吝啬地发表内容并鼓励大家发言,作为领头人引导社区内容蓬勃发展。


“PingCAP特别主张技术驱动,它的开源方式甚至不像一家中国公司。”同为企业服务市场创业者,身份云平台Authing创始人谢扬认为PingCAP的策略是站在技术制高点上:“它发表的内容质量极高,而且从架构师到开发者都在持续发文章到全球最顶尖的工程师平台,其中很多篇甚至是英文文章,吸引中国的译者翻译回来,发表在中国的各类技术营销渠道上。”


另一个让后辈钦佩的特点是,PingCAP前面两年的重心是技术累积,对商业化并不着急。直到2018年,搭载着云端SaaS服务,它的商业化才随之而来。


“云”不仅将企业服务软件的交付进行了标准化,也将提供服务的方式进一步标准化。


首先,PingCAP的产品更新会实时同步给所有客户——这与传统软件厂商的长达几个月的响应时间大相径庭;


此外,通过SaaS,PingCAP实现了高效部署,传统数据库产品需要一年时间部署,PingCAP为代表的云端数据库只需要一两个月;SaaS为PingCAP本身则带来了更为灵活的销售模式,中小企业客户只要绑定信用卡,就可以立即开始使用。


CTO黄东旭记得,刚上线没多久,一家台湾企业就直接绑了一万美金开始使用,很久一段时间PingCAP都不清楚这家企业的业务是什么。


在美团、哔哩哔哩、小米、摩拜等企业迎接用户量暴增的时候,这些企业们同时也成为了PingCAP用户,这意味着它们拥有了更灵活的架构和弹性数据库,不需要由于双十一带来的多倍销售而购买更多服务器。


在国内以金融类为代表的企业需要私有云部署,刘奇曾透露,国内的客单价在百万元量级,国外更是数倍之高。由此它的出海效应也相继产生,公司陆续服务于Square(美国)、PayPay(日本)、Dailymotion(法国)、Shopee(新加坡)、ZaloPay(越南)、BookMyShow(印度)等海外产品。


开源为PingCAP带来的优势不止于此,因为开源,大厂工程师们对开源产品的贡献更是让PingCAP受益匪浅。“现在实际上参与开发PingCAP的人员,已经有1000多个人了。很难想象一个公司,在某一个单项产品上面,投入1000多个研发是个什么概念?而这还只是开发人员。”刘奇说。


在刘奇与团队看来,单点上的巨大投入是让创业公司“活下来、参与竞争,甚至跟巨头去PK”的条件。


这些使PingCAP的TiDB成为了中国本土诞生的现象级开源产品,三位创始人成为了开源商业的传教士。


“PingCAP带了一波节奏,不少开源爱好者也陆续出来创业了,”PingCAP认为,“我们能做的就是让大家看到,在中国还能有这么一帮理想主义者在坚持,同时也没饿死。”涛思数据创始人陶建辉在2019年7月宣布将产品TDengine开源,背后也有老友PingCAP的助力,TDengine将最核心的存储引擎和计算引擎上传到GitHub的两周时间,收集到的Star已经超过了7300。


而作为背后的投资机构,在GGV看来,“开源”是这些toB 产品最重要的加分项,而“开源商业”也成为了一个投资主题。


无论是底层数据处理还是数据产出层,或者更前端的应用;无论是数据库还是物联网、人工智能,理论上,一切产品皆可开源。


TDengine与RT-Thread背后所搭载的是物联网这个万亿市场,但开源为它们插上了翅膀。“尽管目前的开源产品数量不多,但趋势已经形成,将开源产品商业化的创业者会越来越多。”吴陈尧说。


为什么一定要开源?



PingCAP CTO黄东旭在2020年发表了一篇文章,《大教堂终将倒下,但集市永存》,这篇文章的标题与开源爱好者的圣经《大教堂与集市》(Eric Raymond著)呼应:集市的特点是开放式建设、成本低、周期短、品质平庸;大教堂的特点是封闭式建设、成本高、周期长、品质优异。


黄东旭认为,以开源为代表的“集市”将永存。在文章中,他拆解了程序员不愿将自己的代码开放,企业经营者不认可开源作为核心竞争力的逻辑。在他的解读中,除非某家企业能在自己的行业达到彻彻底底的人才垄断,否则它们的“核心”算法都将是对手也能得到的。唯有开源带来的持续迭代与产品升级才能为一家公司赋予生命力。


任何信仰的传教士都肩负重任。“开源”诞生以来,曾带来不少质疑,他身上的标签不仅有“共享智慧”和“无国界”,也有“免费”二字。以至于很多人质疑:开源就意味着源代码免费共享,而免费又如何能形成商业化?


然而,“免费”并非开源的宿命。


1984年,麻省理工大学(MIT)的计算机教授理查德·斯托曼(Richard Stallman)成立基金会FSF(Free Software Foundation),最初目的是以自由免费对抗大公司的授权费要求,但此后基金会成员认为FSF使用的“自由(Free)”这个词让人想到免费使用,而这不是自由软件的内核,他们不希望将开源商业变为公益机构,所以用“开源”(Open-Source)取代了“自由(Free)”。


开源运动的背景下诞生的典型代表就是Linux。


Linux拥有无数系统开发商,它所开创的模式是由多家公司共同主导一款开源产品的商业化变现,最大的一家Linux系统开发商RedHat在2018年以340亿美元被IBM收购,被称为使IBM“付出了60%溢价”;依托Linux开发而成的Android横空出世并成为全球第一大智能手机操作系统,直接威胁了苹果的地位;全球最大开源开发者社区GitHub被微软75亿美元收购……这些“戏剧性”事件让我们看到开源产品的商业价值。


PingCAP早期手绘产品图



尽管开源产品的底层系统(如Hadoop等)来自于大公司的开发成果,尽管拥有全球规模最大且最优秀程序员的Google,Facebook等具备闭源的开发实力,但依托于社会资源的聚集,开源仍然成为了带动科技创新最重要的力量——以至于全球最大的开源公司并非别人,而是Google,Facebook等大厂——每家内部都堪称开源项目的驱动中心。


开源传教士们验证了他们的判断。PingCAP的两组数据尤其值得关注:从2018到2020年的一年多时间,TiDB的SQL层项目发生了30000多次提交,有接近60%的源码被修改。从代码修改效率到提升空间来看,开源项目的表现都十分亮眼。


然而,开源软件商业化却从不是一件容易的事情。全球的开源软件项目有数千万个,三大基金会(Linux、Apache、CNCF)的托管项目有600+,但是真正商业化成功的开源软件的公司却只有10余家,国外的典型代表有Red Hat、Databricks、MongoDB、Elastics、Confluent、HashiCorp等(GGV纪源资本投资了其中的多家企业),而PingCAP则是国内企业的佼佼者。


在商业化方面,PingCAP给出了自己的观点:开源软件本质上是通过放弃一部分通过信息不对称产生的潜在利润,换取了极其高效的传播和场景触及效率,但是有意思的是,实际上牺牲掉的这些潜在利润大概率也不一定真的牺牲掉。


因为,一来可能本身付费能力有限,二来可能实际上这些用户通过宣传站台二次传播或者代码贡献等方式回馈了项目本身;如果一款产品是闭源的,这款产品解决的问题又足够普遍且高价值,那么长远来看一定会有一个开源的解决方案吞掉一切。


吴陈尧则认为,开源模式在增长和商业上都跟To C端互联网公司有着类似的逻辑:


To C端产品在打磨和增长过程中,崇尚通过大量的用户反馈和数据来实现迭代,而开源产品也在高度依赖在社区中去搜集bug和对新功能的需求;


在商业上,伟大的To C产品通常是以先创造用户价值,再探索变现方式的路径实现商业价值,也就是巨大的用户价值(通常可以以用户数和依赖程度来衡量)最终一定会有巨大的商业价值与之相匹配,而开源模式也将用户的喜爱视为一个项目或社区存在的最高目的,坚信商业价值是一个自然而然的过程。


不仅如此,GGV企业服务投资团队认为,开源优势能够做到品牌效应、规模效应以及极低的获客成本,这在巴菲特所提出的护城河即商业壁垒中极为关键。



而我们不能忽略的重要一点是,开源带来的护城河由何而来?


首先,开源社区让无数程序员注意、甚至贡献代码进入某款开源产品,而这些程序员对于自己参与“养成”的产品极其关注并愿意使用。


PingCAP对程序员群体的理解是,很多程序员对物质没有太大的感觉,但骨子里有理想主义情怀,他们更希望做一些影响世人的事情,“想要攀登珠穆朗玛峰”。


也正因此,随着开源社区产品的知名度增高,程序员群体中影响力变强,就出现了越来越多的“销售线索”,因此形成了商业壁垒,并逐渐积累了口碑。


此外,在美国与如今的中国互联网行业,大多IT基础设施的采购是自下而上的,这意味当底层的程序员可以做决策时,他们自然会推荐自己所认可的开源产品。


GGV投资的另一款产品RT-Thread创办于2006年,创始人熊谱翔曾谈到商业化转型中的顺利之处:很多自己上下游企业的CTO与技术团队都贡献了代码到RT-Thread,与他们的合作多是一拍即合,根本无需对产品做过多介绍,积累十几年的影响力已经足以形成转化为销售的势能。



再次,GGV企业服务投资团队认为:互联网行业对开源产品的使用本身已经成为趋势,在当今各类互联网产品团队的代码库中,开源代码的比例在逐渐上升。开源代码不仅免费,而且质量已经被认可,能够为企业节省人力成本和时间成本。


对一家VC而言,一款有极低获客成本的产品意味着足够强的吸引力。不过,在GGV对开源产品的观察中发现,“是否开源”与一款产品的性质有关,偏底层的IT基础设施与操作系统“值得”开源,甚至以开源为最佳、最简单的方案,但是一些前端应用即使开源也很难获得更大的商业化空间。


PingCAP的TiDB,涛思的TDengine,RT-Thread都是底层产品,而且PingCAP的TiDB作为数据库产品所产生的更换成本极高,客户将数据库放入系统后,几乎很难更换,这带来了极高的客户流程。


“是否开源”与这款产品所在的竞争格局也有关,如果所在的市场已有巨头提出解决方案,那么创业公司将不得不用开源的方式实现弯道超车。


RT-Thread创始人熊谱翔提到市场所带来的机遇,在RT-Thread所在的IoTOS赛道上,华为等中外硬件大厂均拥有自己的OS,但很多中小客户宁愿寻找一套中立的系统,而这就带来了RT-Thread等第三方IoTOS的机会。而巨头的解决方案往往可能只适合巨头,并不如创业公司的产品更加专注。


除此之外,开源将无疑助推企业服务产品的出海进程。海外客户对中国诞生的产品普遍仍有一些顾虑,“中国公司出海开源其实是一个比较有机会的模式,甚至有可能是唯一的模式。”吴陈尧说。

 

 

开源英雄的时代


让一向深耕企业服务市场的GGV格外关注开源商业的是一系列案例:MongoDB和Elastic是两家开源代表企业,从传统软件企业的销售方式到开源+SaaS服务之后,市值分别从上市时的18亿美金和25亿美金涨到了如今的247亿美金和140亿美金;GGV在2012年投资的HashiCorp近年客单价增加,并且获得了一系列大客户的青睐,以至于全球500强企业里有100家以上为其客户,而在GGV最初投资的时候,除了Redhat没有其他开源公司上市,况且Redhat的模式也只是基于开源项目Linux进行商业开发。


在大洋彼岸的中国市场,开源的声音从未停止。首先,越来越多的中国开源爱好者成为开源贡献者。中文IT技术交流平台CSDN曾提到,从数量和贡献度上,中国的开发者都已经达到了GitHub全球4000万的注册用户中的第二位;中国的活跃开源项目贡献者,有40%以上都是在2019年内加入的,其中大多都是90后的年轻人。在Github全球公司开源项目贡献榜上,阿里巴巴与腾讯分别位列第5位与第9位。


真正纵身跳入开源创业的中国创业者是少数,但也已形成趋势。这其中,有些是以开源撬动发展的创始人,如PingCAP的刘奇、黄东旭、崔秋和涛思创始人陶建辉,有些则是“老版主”终于选择创业,如熊谱翔。借用HashiCorp创始人Mitchell的话来说,他们的出现是“酝酿了十年的一夜成名”。在开发者社区SegmentFault思否发布的《中国开源先锋33人之心尖上的开源人物》榜单中,黄东旭、陶建辉、熊谱翔均已上榜,而其中更多开源英雄还在大公司麾下。或许几年后,他们姓名前的职称将被书写成为自己创办的企业。



所幸这个市场需要更多开源创业者去改写。Oracle等传统软件巨头是软件创业者的挑战对象。在PingCAP刚成立的2015年,Oracle在中国数据库市场的占有率高达56%,也是很多金融行业客户的首选。但它在中国企业服务尚未起飞的前几年也曾折戟,“中国市场曾是地狱级,”PingCAP透露,“Oracle在整个中国的收入占全球的比例,大概不到3%。”


在中国,企业服务软件不仅有中国巨大的成长空间也有最极端的互联网环境。一方面,在竞争之下,每家企业都渴望自己的架构更灵活,更新速度更快;另一方面,网民数量外加“双十一”等大型事件营销会对各类互联网公司带来不可小视的数据冲击,刘奇认为Google的成功建立在数据处理量极其庞大的前提下。而对于数据库来说,中国市场“场景够极端,能打磨产品”。


凌驾在中国企业服务的大势上,开源创业者将面临特殊的机会。吴陈尧对中国开源创业者的建议是:注重社区的搭建,以技术作为立身之本;从创办之初就注重国际化,鼓励中外工程师共同参与;商业化进程视具体服务的客户群来决定,在社区形成一定的规模后就可以商业化。



*GGV纪源资本企业服务小组:GGV深耕企业服务行业20年,目前在全球11个国家有100家被投企业,其中独角兽企业达23家,已经完成上市的企业有15家。



推荐阅读


涛思数据陶建辉:我在49岁时开启了第3次创业
系统装机量接近8亿,RT-thread创始人熊谱翔:开源是一种内向生长的商业模式




分类
未分类

芯片上的大脑:英国科学家将类人脑干细胞编织在芯片上



  新智元报道  

来源:外媒

编辑:LQ

【新智元导读】人类大脑一直给研究者提供灵感,神经形态计算就是受到人脑低功耗和快速计算的启发而出现的,但其发展受到传统电子学固有局限的阻碍,最近英国阿斯顿大学研究人员发起项目,计划通过研究复杂的人脑回路来克服目前机器学习方法的局限。


人脑一直给研究者提供灵感,神经形态计算受到人脑的低功耗和快速计算特点启发而出现,它或许会是超大规模机器和人工智能应用(如自动驾驶)未来的基石。
 
神经形态芯片的最初思想可以追溯到加州理工学院的Carver Mead 教授在1990年发表的一篇论文。


Mead在论文中提出,模拟芯片能够模仿人脑神经元和突触的活动,与模拟芯片的二进制本质不同,模拟芯片是一种输出可以变化的芯片。


但是目前,神经形态计算的发展受到传统电子学固有局限的阻碍。
 
最近,由英国阿斯顿大学研究人员发起的一个新项目「Neu-ChiP」,展示了如何通过教授在微芯片上培育的人类脑干细胞来解决数据问题,从而为机器学习技术的「范式转变」奠定基础。


该项目为期3年,获得了欧盟委员会的「未来与新兴技术」(Future and Emerging Technologies,FET)项目350万欧元(约2700万人民币)的资助;
 
英国、法国、西班牙、瑞士和以色列的高校和机构也参与其中,包括英国罗浮堡大学、巴塞罗那大学、法国国家科学研究中心、以色列理工学院和3Brain AG 公司。

芯片上的大脑


在Neu-ChiP项目中,研究小组将把类似于人类大脑皮层的干细胞网络分层放在微芯片上。然后通过向细胞发射不断变化的光束模式来刺激细胞。

 
项目利用先进的3D电脑模型可以观察细胞发生的任何变化,了解他们的适应能力如何。
 
这模仿了人类大脑的可塑性,可以迅速适应新的信息。
 
据悉,该项目将在培养皿中设计神经元回路并训练它们进行数据分析的能力,将为大脑如何计算信息并找到解决方案提供新的见解。
 
开发的技术甚至可能有助于设计独特的人机界面。
 
而且,该项目不仅要建立一个由许多非常复杂的人类神经细胞组成的系统模型,研究人员还将尝试超越这个模型,将神经系统驱动到一个能够进行非平凡计算的状态。

芯片上的大脑:致力于突破人工智能的界限(cr: 3Brain AG)

项目的生物学专家表示,这个项目将致力于寻求建立神经形态电路,并将新兴的电子设备与生物神经元结合起来。
 
在合成生物学的背景下,看到活细胞中的计算是如何从数字化通过模拟进化到神经形态计算范式,这将会令人印象深刻。
 
阿斯顿大学数学教授David Saad说: 「我们的目标是利用人类大脑无与伦比的计算能力,极大地提高计算机帮助我们解决复杂问题的能力。我们相信,这个项目有可能突破目前处理能力和能源消耗的局限,从而带来机器学习技术的范式转变。」
 
 

参考链接:

https://eurekalert.org/pub_releases/2021-01/au-sca012621.php

https://futurism.com/the-byte/scientists-weaving-human-brain-cells-microchips



分类
未分类

2023年超过1000量子比特!IBM公布量子计算开发路线图



  新智元报道  

来源:Venturebeat

编辑:LQ

【新智元导读】为了在5年内实现量子计算商业应用,IBM称,它有具体方案来提升其量子硬件的功率和可靠性。IBM的Qiskit的开源量子编程框架将帮助应用程序实现「100倍」加速,这样,目前需要花费几个月时间处理的工作可以在几小时内完成。


围绕量子计算的炒作仍在继续,有声音质疑那些权威的预测,同时也有越来越多的风险资本涌入这个领域。
 
一直走在规划前沿的IBM在2020年9月公布了一份量子计算发展路线图,强调IBM有信心将在量子计算方面产生重大影响。
 
 
为了在5年内实现量子计算商业应用,IBM称,它有一个可以实现的时间表来提升其量子硬件的功率和可靠性。
 
接下来的挑战是如何让公司和开发人员开始尝试编写应用程序,使他们能够利用这种能力。
 
IBM 负责量子生态系统开发的副总裁Bob Sutor说: 「目前还没有人在商业上使用量子计算。」
 
 
「这将发生在2025年左右。但这不是睡了一觉第二天醒来就能成为专家的事情。所以,看到的是,该领域的前沿领导会转向新技术,并开始对其进行试验,研发新技术。」
 
Bob Sutor是IBM研发的20年老将、量子技术方面的专家,曾经出过一本书《与量子比特共舞》(Dancing with Qubits)
 
 
IBM 在研发量子计算方面一直非常积极。
 
2016年,该公司推出了Q网络,允许公司通过公司的云服务开始量子计算机实验。
 
根据 Sutor 的说法,现在应用Q网络的有超过135个组织,包括摩根大通和埃克森美孚这样的公司,还有大学和初创公司。
 
根据 IBM 的量子硬件路线图,该公司希望今年达到100量子位(量子计算机处理能力的计量单位) ,明年达到400量子位,到2023年达到1000量子位。
 
尽管要使量子计算优于传统计算还有很大的科学障碍需要克服,但Sutor说IBM在克服这些障碍方面处于强有力的位置。
 
 
「这意义重大,因为它代表着我们现在在科学和工程上已经有信心,我们能够突破只拥有小系统的束缚,进入到更大的系统,我们需要量子计算能够比传统系统做的更好。」他说。
 

量子计算的下一步


这使人们更加关注公司将如何利用这种新的计算能力,以及如何让他们参与进来的问题,比如设定多高的期望值。
 
「当我们谈论量子计算时,你要记住的第一件事是,它不是传统计算机的批发替代品,」Sutor 说。「我们不会扔掉传统电脑。量子计算机需要传统系统才能工作。」
 
Sutor说,量子计算机最适合用于卸载某些特定任务。量子更强大计算将使自然科学和化学,问题优化,以及人工智能的一些部分等最有前途的领域获益。
 
在这些应用场景中,可以想象一个开发者正在他们的笔记本电脑上运行一个应用程序,但是在特定的阶段通过云将一个请求发送到量子计算机执行计算,然后返回到那台笔记本电脑。
 
为了使这个方程的量子部分更容易理解,IBM创建了一个名为Qiskit的开源量子编程框架。说,Qiskit将帮助应用程序实现「100倍」加速,这样,目前需要花费几个月时间处理的工作可以在几小时内完成。
 
 

Big tech的量子霸权之争

 

量子计算领域的主流玩家有IBM,谷歌,英特尔、微软以及亚马逊,这些big tech一直在争夺「量子霸权」。
 
2019年10月,谷歌正式在Nature发表了相关论文,称其量子计算机在200秒内完成了特定任务的计算。
 
 
根据实验中的测量结果,而世界上最快的超级计算机需要10000年才能产生类似的结果,由此,Google宣布率先实现了「量子优越性」。
 
但是第二天IBM马上站出来揭短:该计算机是宣传性哗众取宠产品,运作方式依然没有超出目前量子科技范围,其只在特定条件特定问题下的一种实验问题结果,而传统计算机只要更换算法就能达到同样效果,成本还更低、正确率更高,这被科技期刊称为「量子门」争议事件。
 
不过论文还是发表了,谷歌CEO 皮采回应道:「人类历史第一架飞机仅仅飞行了12秒钟,没有实用价值,但它证明了飞机是可以飞的」,这也让Google在量子计算上取得了一定的领先优势。
 
2019年2月,AWS推出了量子计算服务Braket的预览版,并成立了AWS量子计算中心和量子解决方案实验室;
 
2018年1月,英特尔展示了49量子位的超导量子测试芯片「Tangle Lake」;
 
同年11月,微软发布了云上的量子计算工具,企业用户可以使用它加强传统计算机的算力……
 
此外还有我国潘建伟团队光量子计算系统「九章」。
 
 
根据现有理论,其速度比目前世界排名第一的超级计算机日本「富岳」快一百万亿倍,比去年谷歌发布的53个超导比特量子计算原型机「悬铃木」快一百亿倍。
 
2017年,中国科大潘建伟、陆朝阳团队用一种共振激发的量子点光源,能产生确定性的高品质单光子,此外,他们自主设计研发了高效率的线性光学网络。
 
「九章」实现了76个量子位的计算,这比去年谷歌发布的量子计算机,其算法运行在一个由53个量子位组成的量子芯片上,在量子数量上超出了近50%,实现了所谓「量子霸权」的突破。
 
不过,量子计算仍在非常早期的阶段,目前巨头们争夺的不只是市场份额,而是量子计算领域的话语权甚至未来的定义权,而这注定是一场持续「烧钱」,且短期内看不到金钱回报的战争。
 


参考链接:
https://venturebeat.com/2021/02/03/ibm-quantum-computing-development-roadmap-envisions-applications-running-100-times-faster/
https://www.ibm.com/blogs/research/2021/02/quantum-development-roadmap/
https://tech.sina.com.cn/it/2020-01-10/doc-iihnzhha1493330.shtml



分类
未分类

印度天才数学家拉马努金留下的3000+神奇公式,交给AI来「证明」!



  新智元报道  

编辑:Q
【新智元导读】近日,《自然》杂志上发表了一个项目,有研究人员建立了一个AI算法项目 ,可以产生新的数学公式,且其中一些公式很难证明是否是正确的。这个项目以印度传奇数学家拉马努金(Srinivasa Ramanujan)命名。

 

2016年4月,著名投资人尤里·米尔纳 (Yuri Milner) 在自己家中举行了一场小规模的晚宴,到场的嘉宾包括Google CEO 皮查伊、创始人布林、Facebook CEO 扎克伯格及其他数十位硅谷领袖等。

 

米尔纳当晚放映了一部传记体电影——《知无涯者》,而影片讲述的正是传奇数学家拉马努金的一生。

 

 

据报道,宴会结束后,扎克伯格等人是红着眼眶走出来的,他们当即宣布将联手成立一项新基金,以纪念拉马努金。

 

 

拉马努金是二十世纪最传奇的数学家之一:他独立发现了近3900个数学公式和命题,几乎没受过正规的高等数学教育的他,却能凭直觉写出不平凡的定理和公式,且往往被证明是正确的。同时还留了世人很多自己的笔记,引发了后来的大量研究。

 

 

其中几个由他发现的神奇公式如下:

 

拉马努金圆周率公式:

 

 

拉马努金常数(几乎是一个整数):

 

 

拉马努金连根式:

 

 

拉马努金余弦立方根公式:

 

 

正是这些美妙的数学公式,让激起了研究人员的兴趣。

 

设计 Ramanujan 机器的目的是产生计算重要数学常数(如 π 或 e)数字的新方法,其中许多常数是无理数,这意味着它们有无数个不重复的小数。

 

像 e 和 π 这样的基本常数在不同的科学领域无处不在,包括物理学、生物学、化学、几何学和抽象数学。然而,几个世纪以来,与基本常数有关的新的数学公式很少,而且通常是凭借数学直觉或创造力偶尔发现的。

 

Ramanujan 机器可以从众所周知的公式开始计算数字,例如 π 的前几千位数字。从这些数据中,该算法试图预测一个新的表达式,这个表达也可以做同样的计算得到相同的结果。

 

 

这个过程会产生一个很好的猜测(conjecture),然后就要靠人类数学家来证明这个表达式是否能够正确地计算出整个数字。

 

 

该团队在2019年开始就在该项目的网站上公开这些推测,研究人员已经证明了其中的一些猜测是正确的。

 

但有些问题仍有待解决,其中一个是关于 Apery 常数的问题,Apery 常数在物理学中有重要应用。最后一个结果,也是最令人兴奋的一个,但是没有人知道如何证明」,物理学家 Ido Kaminer 说,但是算法自动创造的推测可以指引数学家们找到人们不知道存在的数学分支之间的联系

 

连分数(Continued fractions)

 

拉马努金机器目前的应用还十分有限: 到目前为止,算法只能生成一个特定类型的式子,称为连分数。这些分数表示一个数字为一个无限的分数序列,这些分数嵌套在彼此的分母中。

 

团队人员已经尝试了一系列算法来寻找连分数,并将它们应用到各种概念上重要的数字上。其中一个是加泰罗尼亚常数(Catalan’s constant),这个数字起源于十九世纪比利时数学家欧仁 · 加泰罗尼亚的研究。

 

 

加泰罗尼亚常数大约为0.916,但它是如此神秘,以至于没有人知道它是否是有理的,也就是说它是否可以表示为两个整数的分数。

 

数学家们能做的最好的事情就是证明它的非理性指数」——用有理数来近似一个数字的难度的度量,这个值至少是0.554。证明加泰罗尼亚常数是无理的等价于证明其非理性指数大于1。而由拉马努金机器生成的公式,使卡米纳的团队在最好的人类结果上略有改善,使指数达到0.567。

 

增加复杂性(Increasing complexity)


自动生成猜测并不是计算机帮助推动数学发展的唯一领域。

 

计算机辅助计算在几个引人注目的结果的证明中发挥了关键作用。最近,一些数学家在人工智能方面取得了进展,人工智能不仅能进行重复的计算,还能自己做出证明。另一个正在发展的领域是软件,它可以检查人类写的数学证明,并检查它是否正确。

 

「最终,人类将会被淘汰」,Zeilberger 说,他是证明自动化领域的先驱,并且帮助证实了 Ramanujan 机器的一些猜想,随着人工智能产生的数学的复杂性增加,数学家们将只能粗略地理解计算,他补充道。

 

不过,尽管计算机可能能够提出数学陈述,甚至证明它们是正确的,但是如果没有人类的干预,目前还不清楚它们是否能够区分深刻的,有趣的陈述,还是仅仅从技术上是正确的而已。

 

如果感兴趣的话,你可以在下面的链接中运行 Ramanujan 算法来发现新的数学猜想,如果能够证明是正确的,那么发现的新猜想将以你的名字命名!

 

 

参考链接:

http://www.ramanujanmachine.com/

Github项目链接:

https://github.com/AnonGit90210/RamanujanMachine



分类
未分类

重磅推荐!我在Github上找到一个超级轻量、灵活的SQL工具

开源最前线(ID:OpenSourceTop) 猿妹综合整理

综合自:https://github.com/HVF/franchise


今天,猿妹和大家推荐一款轻量级但功能强大的 SQL 工具,带有 notebook 界面。无需安装和注册,即可快速安全地使用数据——Franchise



目前,Franchise在Github上标星 3.7K,累计分支 243。(Github地址:https://github.com/HVF/franchise


Franchise主要功能特性特性



如果你的数据是CSV、JSON或XLSX文件,加载它就像将文件放到Franchise中一样简单。如果你想在浏览器中运行SQLite引擎的一个版本,所有的处理都在本地进行。



如果你想要连接到PostgreSQL, MySQL或BigQuery,在你终端上运行一个命令建立数据库桥,它将会通过你的计算机直接连接到你的数据库,但是你的数据永远不会进入SQLite的服务器。



Franchise还为时间序列数据构建了许多可视化工具——散点图、柱状图、折线图、地图等等。


Franchise运行方式

Franchise有在线运行版本,链接地址:https://franchise.cloud/,以下是在开发模式下运行Franchise的方法:

1.打开一个终端并运行

git clone --depth 1 https://github.com/HVF/franchise.git


2.cd进入项目目录


cd franchise


3.安装项目依赖项


yarn install


4.启动开发服务器


yarn start


5.打开浏览器并转到 http://localhost:3000

6.在franchise/src里面编辑文件,保存后,浏览器会自动重新加载

7.添加功能并发送PR。




分类
未分类

如何打造一个高性能的前端智能推理引擎

上图的相机的智能识别是怎么做到的呢?请往下看。


什么是前端智能推理引擎


在前端智能推理引擎之前,我们先来说一下什么是”端智能”

端智能(On-Device Machine Learning)是指把机器学习的应用放在端侧做。这里的“端侧”,是相对于云服务而言的。它可以是手机,也可以是 IOT 设备等。

传统的机器学习,由于模型大小、机器算力的问题,很多是放在服务端做的。比如 Amazon AWS 有“Amazon Rekognition Service”,Google 有 “Google Cloud Vision Service”。而随着以手机为代表的端侧设备算力的提高,以及模型设计本身的演进,大小更小、能力更强的模型逐渐能够部署到端上运行。

–参考自《https://www.infoq.cn/article/m5m93qyadscnyil3kprv

相比云端部署的方式,APP端拥有更直接的用户特征,同时具备如下优势:
  • 实时性高,端侧处理可节省数据的网络传输时间。
  • 节省资源,充分利用端侧算力和存储空间。
  • 隐私性好,产生数据到消费数据都在端侧完成,避免传输引起的隐私泄露风险

这些是端智能的优势,但它不是万金油,仍然存在一些局限性:
  • 设备资源有限,端侧算力、存储是有限的,不能做大规模高强度的持续计算。
  • 算法规模小,端侧算力小,而且单用户的数据,在算法上并不能做到最优。
  • 用户数据有限,端侧数据不适合长期存储,同时可用数据有限。

同理,前端智能是指将机器学习的应用放到前端上(web、h5、小程序等).

所以,什么是前端智能推理引擎呢?

如下图:
前端智能推理引擎实际上就是利用前端上算力去执行模型的那个东西。


业界现有的前端推理引擎


这里列出三个常见的推理引擎
  • tensorflow.js(下面简称为tfjs)
  • ONNX.js
  • WebDNN

对于一个端上推理引擎来说,最重要的是什么?当然是性能了!性能越好,也代表在端上的应用场景也会越多,下面我们来看下这三个推理引擎的性能对比:

(下面数据使用模型为MobileNetV2分类模型)

cpu(js计算)



可以看到,在纯JS环境下进行计算,仅仅做一次分类都要1500ms以上。设想一下如果一个相机需要实时对拍摄的物体做分类预测(比如预测拍摄的对象是猫还是狗),那么每预测一次需要1500ms,这样的性能是无法忍受的。

WASM



在WASM环境下,性能最佳的ONNX.js达到了135ms的性能,也就是7fps左右,已经到了勉强能用的程度了。而tfjs却是糟糕的1501ms。这里是因为onnx.js利用了worker进行多线程加速,所以性能最好。


WebGL(GPU)



最后是GPU环境,可以看到tfjs和ONNXjs的性能都达到了比较好的性能水平,而WebDNN表现较为糟糕。

除了上面这三种引擎,目前国内还有百度的paddle.js以及淘宝的mnn.js等,这里不做讨论。

当然,在选择一个合适的推理引擎时,除了性能以外,还有生态、引擎维护情况等等一系列的考虑。从综合的方面来说,tfjs是当下市场上最适合的前端推理引擎。因为tfjs可以依靠tensorflow的强大的生态、google官方团队的全职维护等。相比之下ONNX框架比较小众,且ONNXjs已经有近一年没有维护了。WebDNN性能及生态都没有任何竞争力。


前端上的高性能计算方案



从上一章节其实能看到,在前端上做高性能计算一般比较普遍的就是WASM和基于WebGL的GPU计算,当然也有asm.js这里不做讨论。


WASM


WASM大家应该是比较熟悉的,这里只做下简短的介绍:

WebAssembly是一种运行在现代网络浏览器中的新型代码,并且提供新的性能特性和效果。它设计的目的不是为了手写代码而是为诸如C、C++和Rust等低级源语言提供一个高效的编译目标。

对于网络平台而言,这具有巨大的意义——这为客户端app提供了一种在网络平台以接近本地速度的方式运行多种语言编写的代码的方式;在这之前,客户端app是不可能做到的。

而且,你在不知道如何编写WebAssembly代码的情况下就可以使用它。WebAssembly的模块可以被导入的到一个网络app(或Node.js)中,并且暴露出供JavaScript使用的WebAssembly函数。JavaScript框架不但可以使用WebAssembly获得巨大性能优势和新特性,而且还能使得各种功能保持对网络开发者的易用性。–《摘自MDNWebAssembly概念


WebGL


啥?WebGL不是做图形渲染的吗?不是做3D的吗?为啥能做高性能计算?

可能一些同学听说过gpgpu.js这个库,这个库就是利用webgl做通用计算的,具体的原理是怎么样的呢?(为了能够继续往下阅读,请先快速浏览下这篇文章):《利用WebGL2 实现Web前端的GPU计算》。



将推理引擎的性能进行极致优化



好了,目前我们知道在前端上的两种高性能计算方式了,那么如果现有的框架(tfjs、onnxjs)性能上就是不满足我们的需求怎么办呢?怎么样才能进一步提升引擎性能,并落地生产环境呢?

答案是:手撕源码,优化性能。对,就是这么简单粗暴。以tfjs为例(其他的框架原理上是一致的),下面给大家介绍下如何用不同的姿势去优化引擎性能。

在去年年初时候,我们团队和google的tfjs团队做了一次深入交流,google那边明确表示tfjs后面的发展方向以WASM计算为主、webgl计算不做新的feature以维护为主。但是现阶段各浏览器、小程序对WASM的支持并不完整(例如SIMD、Multi-Thread等特性),所以WASM暂时无法在生产环境落地。所以,现阶段还是需要依赖webgl的计算能力。糟糕的是,此时tfjs的webgl性能在移动端上表现依旧差强人意,尤其在中低端机上的性能完全达不到我们的业务要求。没办法,只能自己硬着头皮进去优化引擎。所以以下的内容都是针对于webgl计算进行介绍。


优化 WebGL 高性能计算的n种姿势


姿势一:计算向量化


计算向量化是指,利用glsl的vec2/vec4/matrix数据类型进行计算,因为对于GPU来说,最大的优势就是计算并行化,通过向量去计算能够尽可能地达到并行化的效果。

例如一次矩阵乘法:
c = a1 * b1 + a2 * b2 + a3 * b3 + a4 * b4;
可以改为
c = dot(vec4(a1, a2, a3, a4), vec4(b1,b2,b3,b4));

向量化的同时也要配合内存布局的优化;


姿势二:内存布局优化


如果读了上面《利用WebGL2 实现Web前端的GPU计算》这篇文章的同学应该了解到,在GPU内所有的数据存储都是通过Texture的,而Texture本身是一个 长n * 宽m * 通道(rgba)4 的东西,如果我们要存一个3 * 224 * 224 * 150的四维矩阵进去要怎么办呢?肯定会涉及到矩阵的编码,即以一定的格式把高维矩阵存进特性形状的Texture内,而Texture的数据排布又会影响计算过程中的读存性能。例如,举一个较简单的例子:


如果是常规内存排布的话,计算一次需要按行或者案列遍历矩阵一次,而GPU的cache是tile类型的,即n*n类型的缓存,根据不同芯片n有所不同。所以这种遍历方式会频繁造成cache miss,从而成为性能的瓶颈。所以,我们就要通过内存排布的方式进行性能优化。类似下图:




姿势三:图优化


由于一个模型是一个一个的算子组成的,而在GPU内每个算子被设计成一个webgl program,每次切换program的时候会造成较多的性能损耗。所以如果有一种手段能够减少模型的program数量,对性能的提升也是十分可观的。如下图:



我们将一些可以融合的节点在图结构上进行融合(nOP -> 1OP),基于新的计算结点实现新的OP。这样一来大大减少了OP的数量,进而减少了Program的数量,所以提升了推理性能。在低端手机上效果尤为明显。

姿势四:混合精度计算


以上所有的计算都是基于常规浮点数计算,也就是float32单精度浮点数计算。那么,在GPU内是否能实现混合精度的计算呢?例如float16、float32、uint8混合精度的计算。答案是可以的,在GPU内实现混合精度计算的价值是在于提升GPU的bandwidth。由于webgl的texture每一个像素点包含rgba四个通道,而每个通道最高为32位,我们可以在32位内尽可能存储更多的数据。如果精度为float16,那么可以存储两个float16,bandwidth就是之前的2倍,同理uint8的bandwidth是之前的4倍。这个性能的提升就是巨大的。还是上图说话吧:


姿势n:…


优化的手段还有很多,这里就不一一列举了。



引擎落地的场景



目前,基于我们深度优化的引擎已经落地蚂蚁集团及阿里经济体多个应用场景,比较典型的就是文章开头演示的宠物识别,还有卡证识别、碎屏相机等等等场景。

业界的有之前比较火的虚拟试妆小程序等。


读到这篇文章的朋友们也可以打开你们的脑洞,挖掘出更多更好玩的智能场景。


未来展望



随着市面是机型的更新换代及引擎的深入优化,我相信tfjs会在更多富交互的场景上大放异彩,例如拥有AI能力的前端游戏、AR、VR等等场景。现在我们要做的就是静下心来,站在巨人的肩膀上持续打磨我们的引擎,愿等花开。





电子书免费下载

《2021前端热门技术解读》



阿里巴巴前端委员会重磅推荐!阿里巴巴前端技术专家为你解读前端技术新趋势以及2021你需要关注的技术热点,覆盖前端安全生产、跨端技术、Node.js(Serverless)以及多样化的前端技术四大方向,是2021不容错过的前端学习手册。


关注 Alibaba F2E 公众号

回复 电子书 马上下载


分类
未分类

Docker 的底层原理,了解它只需要 5分钟~

一位同学曾给我打比方:宿主机就好比一间大房子,docker 把它成了N个小隔断。在这些小隔断之间,有独立的卫生间、小床、电视…

麻雀虽小,五脏俱全,这个比喻非常的贴切。Linux 提供了非常全面的隔离机制,使得每个小隔间互不影响。即使隔壁小间满室春光,我的小房间一样的冷清,对我毫无影响。

Docker 能实现这些功能,依赖于 chroot、namespace、cgroup 等三种老技术。我们本篇文章,就先聊一下 namespace 方面的东西。毕竟隔离是容器的第一要素。

Linux 的内核,提供了多达8种类型的 Namespace。在这些独立的 Namespace 中,资源互不影响,隔离措施做的非常好。

1. 8种类型

我们先来看一下,Linux都支持哪些Namespace。可以通过 unshare 命令来观察到这些细节。在终端执行 man unshare,将会出现这些 Namespace 的介绍。

  1. Mount(mnt) 隔离挂载点

  2. Process ID (pid) 隔离进程 ID

  3. Network (net) 隔离网络设备,端口号等

  4. Interprocess Communication (ipc) 隔离 System V IPC 和 POSIX message queues

  5. UTS Namespace(uts) 隔离主机名和域名

  6. User Namespace (user) 隔离用户和用户组

另外,Linux 在 4.6 版本,5.6 版本,分别加入了 cgroups 和 Time 两种隔离类型,加起来就有8种。
  1. Control group (cgroup) Namespace 隔离 Cgroups 根目录 (4.6版本加入)
  2. Time Namespace 隔离系统时间 (5.6版本加入)

2. 1个例子

通过unshare命令,可以快速建立一些隔离的例子,我们拿最简单直观的pid namespace来看一下它的效果。
众所周知,Linux 进程号为1的,叫做systemd进程。但在 Docker 中,我们通过执行ps命令,却只能看到非常少的进程列表。

执行下面的命令,进入隔离环境,并将 bash 作为根进程:

unshare --pid --fork --mount-proc /bin/bash
效果如图所示。可以看到,我们的 bash,已经成为了1号进程,而宿主机和其他隔离环境的进程信息,在这里是不可见的。

先在隔离环境中,执行sleep 1000。再开一个终端,在宿主机上执行pstree,我们将会看到这个隔离环境的进行信息。

接下来,在宿主机上,把 sleep 对应进程的命名空间信息,和宿主机的命名空间信息作一下对比。可以看到,它们的pid namespace,对应的数值是不同的。

下面给出其他 namespace 的实验性命令,你可以实际操作一下。

3. 试验一下

unshare --mount --fork /bin/bash

创建mount namespace,并在每个不同的环境中,使用不同的挂载目录。

unshare --uts --fork /bin/bash

uts 可以用来隔离主机名称,允许每个 namespace 拥有一个独立的主机名,你可以通过hostname命令进行修改。

unshare --ipc --fork /bin/bash
IPC Namespace 主要是用来隔离进程间通信的。Linux 的进程间通信,有管道、信号、报文、共享内存、信号量、套接口等方式。使用了 IPC 命名空间,意味着跨 Namespace 的这些通信方式将全部失效!不过,这也正是我们所希望的到的。
unshare --user -r /bin/bash
用户命名空间,就非常好理解了。我们可以在一个 Namespace 中建立 xjjdog 账号,也可以在另外一个 Namespace 中建立 xjjdog 账号,而且它们是相互不影响的。
unshare --net --fork /bin/bash
net namespace,这个就非常有用了。它可以用来隔离网络设备、IP 地址和端口等信息。

End

可以看到,通过各种 Namespace,Linux 能够对各种资源进行精细化的隔离。Docker本身也是一个新瓶装旧酒的玩具。Docker 的创新之处,在于它加入了一个中央仓库,并封装了很多易用的命令。

你可能会发现,到目前为止,我们并没有对 Cpu和内存的资源使用进行隔离,也没有对应的 Namespace 来解决这些问题。

资源限制的功能,是使用Cgroups进行限额配置来完成的,和Namespace没什么关系。我们将在后面的文章,介绍 Cgroups 这项技术。

最后,附上 Docker 的一张生命周期图。来源(http://docker-saigon.github.io/post/Docker-Internals/ )。有需要的同学可以加我的好友获取。

Docker 发展到现在,应用工具链已经非常成熟了,很多同学已经驾轻就熟,如果你对容器技术非常感兴趣,不如多看一下最底层的原理。这样,不管是谷歌推自己的容器,还是继续使用 docker,都能快速把它掌握。
来源:本文转自公众号小姐姐味道(xjjdog),点击查看原文
近期好文:

一文理解 Kubernetes 的存储系统机制

“高效运维”公众号诚邀广大技术人员投稿,

投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118.
点个“在看”,一年不宕机
分类
未分类

10 个 GitHub 上超火和超好看的管理后台模版,后台管理项目有着落了

Web 开发中几乎的平台都需要一个后台管理,但是从零开发一套管理后台模版并不容易,幸运的是有很多开源免费的管理后台模版可以给开发者使用。

那么有哪些优秀的开源免费的管理后台模版呢?

我在 GitHub 上收集了一些优秀的管理后台模版,而且是还在不断更新和维护的项目,并总结得出 Top 10。

1. vue-Element-Admin

vue-element-admin 是一个后台前端解决方案,它基于 vue 和 element-ui实现。

它使用了最新的前端技术栈,内置了 i18n 国际化解决方案,动态路由,权限验证,提炼了典型的业务模型,提供了丰富的功能组件,它可以帮助你快速搭建企业级中后台产品原型。

同时配套了系列教程文章,如何从零构建后一个完整的后台项目。

  • 手摸手,带你用 vue 撸后台 系列一(基础篇)
  • 手摸手,带你用 vue 撸后台 系列二(登录权限篇)
  • 手摸手,带你用 vue 撸后台 系列三 (实战篇)
  • 手摸手,带你用 vue 撸后台 系列四(vueAdmin 一个极简的后台基础模板)
  • 手摸手,带你用 vue 撸后台 系列五(v4.0新版本)
  • 手摸手,带你封装一个 vue component
  • 手摸手,带你优雅的使用 icon
  • 手摸手,带你用合理的姿势使用 webpack4(上)
  • 手摸手,带你用合理的姿势使用 webpack4(下)

该项目还在一直维护中。

而且也是配有使用文档的,很不错。

Github Star 数 62.2K, Github 地址:

https://github.com/PanJiaChen/vue-element-admin

2. iview-admin

iView Admin 是基于 Vue.js,搭配使用 iView UI 组件库形成的一套后台集成解决方案,由 TalkingData 前端可视化团队部分成员开发维护。

iView Admin 遵守 iView 设计和开发约定,风格统一,设计考究,并且更多功能在不停开发中。

不过该项目已经一年多没有更新维护了,估计是在等出了配合 Vue3 相关的 iView UI 库再更新了吧。

而且也是配有使用文档的,很不错。

Github Star 数 15.3K,Github 地址:

https://github.com/iview/iview-admin

3. vue-admin-template

这是一个极简的 vue admin 管理后台。它只包含了 Element UI & axios & iconfont & permission control & lint,这些搭建后台必要的东西。

目前版本为 v4.0+ 基于 vue-cli 进行构建,若你想使用旧版本,可以切换分支到 tag/3.11.0,它不依赖 vue-cli

极简版,就是 vue-Element-Admin 的简化版,功能简单一点,方便快速开发用的。

而且也是配有使用文档的,很不错。

Github Star 数 12K,Github 地址:

https://github.com/PanJiaChen/vue-admin-template

4. ant-design-pro

开箱即用的中台前端 / 设计解决方案。

Ant Design Pro 是基于 Ant Design 和 umi 的封装的一整套企业级中后台前端/设计解决方案,致力于在设计规范和基础组件的基础上,继续向上构建,提炼出典型模板/业务组件/配套设计资源,进一步提升企业级中后台产品设计研发过程中的『用户』和『设计者』的体验。

随着『设计者』的不断反馈,我们将持续迭代,逐步沉淀和总结出更多设计模式和相应的代码实现,阐述中后台产品模板/组件/业务场景的最佳实践,也十分期待你的参与和共建。

Ant Design Pro 在力求提供开箱即用的开发体验,为此我们提供完整的脚手架,涉及国际化,权限,mock,数据流,网络请求等各个方面。

为这些中后台中常见的方案提供了最佳实践来减少学习和开发成本。

而且也是配有使用文档的,很不错。

Github Star 数 27.2K,Github 地址:

https://github.com/ant-design/ant-design-pro

5. ngx-admin

基于Angular 10+ 的可定制管理仪表板模,还拥有 6 个惊人的视觉主题。

Github Star 数 21.7K,Github 地址:

https://github.com/akveo/ngx-admin

6. vue-admin-beautiful

vue-admin-beautiful 是一款基于 vue+element-ui 的绝佳的中后台前端开发管理框架(基于 vue/cli 4 最新版,同时支持电脑,手机,平板)。

vue-admin-beautiful-pro 拥有四种布局(画廊布局、综合布局、纵向布局、横向布局)四种主题(默认、海洋之心、绿茵草场,荣耀典藏),共计 16 布局主题种组合,满足所有项目场景。

已支持常规 bug 自动修复,前端代码自动规范,代码一键生成等众多功能,可以在完全不依赖后台的情况下独立开发完成项目,以及接口自动模拟生成,支持 JAVA、PHP、NODE、.NET、Django 等常用所有后台对接,甚至完全放弃 JAVA 等常规后端开发,内置 node 服务支持直接操作数据库进行增删改查,支持当前流行的 unicloud、serverless 云开发。

该项目还在不断更新和维护中,不错。

https://github.com/chuzhixin/vue-admin-beautiful

7. vuestic-admin

这是一个免费与美妙 Vue.js 管理模板,包括 38 以上个定制用户界面组件。

响应布局 | 图表(Charts.js) | 进度表 | 表格 | 选辑 | 日期选择器 | 复选框和单选框 | 静态表与数据表 | medium editor | 平滑设计字体 | 按钮 | 塌缩 | 颜色选择器 | 时间线 | 土司通知 | 工具提示 | 弹窗 | 图标 | 自旋体 | 模式 | 文件上传 | 厚切薯条通知 | 树 | 卡片 | 等级 | 滑动器 | 聊天系统 | 地图(Google, Yandex, Leaflet, amMap) | 登录/注册页模板 | 404页模板 | i18n

Github Star 数 7.6K,Github 地址:

https://github.com/epicmaxco/vuestic-admin

8. antd-admin

一套优秀的中后台前端解决方案。

特性

  • 国际化,源码中抽离翻译字段,按需加载语言包
  • 动态权限,不同权限对应不同菜单
  • 优雅美观,Ant Design 设计体系
  • Mock 数据,本地数据调试

而且也是配有使用文档的,很不错。

https://github.com/zuiidea/antd-admin

9. eladmin

一个简单且易上手的 Spring boot 后台管理框架

技术栈

使用 SpringBoot、Jpa、Security、Redis、Vue 等前后端前沿技术开发。

模块化

后端采用按功能分模块开发方式,提升开发,测试效率。

高效率

项目简单可配,内置代码生成器,配置好表信息就能一键生成前后端代码。

分离式

前后端完全分离,前端基于 Vue,后端基于 Spring boot。

响应式

支持电脑、平板、手机等所有主流设备访问。

易用性

几乎可用于所有 Web 项目的开发,如 OA、Cms,网址后台管理等。

前后端都有,还是挺不错的。

https://github.com/elunez/eladmin

10. AdminLTE

AdminLTE 是一个完全响应的管理模板。基于 Bootstrap 4.5 框架以及 JS / jQuery 插件。

高度可定制且易于使用。适合从小型移动设备到大型台式机的多种屏幕分辨率。

AdminLTE 的所有 JS,SCSS 和 HTML 文件均经过精心编码,并带有清晰的注释。SCSS 已用于提高代码的可定制性。

ui 风格也不偏向于外国吧,比较简结。

好的地方是还一直在更新和维护,最大的不足就是还依赖于 jQuery 这个旧时代的产物,唉。

Github Star 数 36.8K 也非常高 , Github 地址:

https://github.com/almasaeed2010/AdminLTE




分类
未分类

马斯克脑机接口下一步:让大猩猩用脑电波玩视频游戏,今年人体试验!



  新智元报道  

来源:外媒

编辑:小匀、LQ

【新智元导读】火星计划怎么样了?脑机接口进展又如何?语出惊人的马斯克又来了,近期采访中他又放下狠话:五年半内登火星,还透露说,Neuralink想要造出一只通灵的猴子能打电脑游戏。


人类还有多久能登陆火星?
 
十年?百年?
 
马斯克表示,没那么长!
 
近期,这位疯狂的企业家做客一档电台节目,大谈当下的几大热点,信息量很大,所谈内容都站在现在与未来的焦点。
 
他还透露自己的近期计划,其中包括公布脑机接口进展和他那雄心勃勃的火星计划
 
采访音频戳:https://www.youtube.com/watch?v=wF2TrKF6HEY
 

2026年登火星


NASA的Artemis计划2033年左右登陆火星,而马斯克的SpaceX 2026年就可以实现登陆火星。
 
不仅5年半内登火星,往返火星和地球之间的时间也大大缩短——一个月,而此前天文学家预测的是6个月。
 
据马斯克介绍,接下来5年里,SpaceX将会致力于开发人类往返太阳系里第三、第四块「石头」所需的技术。
 
 
虽然还有几项重大技术需要实现突破,但马斯克表示5年的时间也已经足够做好准备。
 
马斯克还表示,SpaceX需要完善可重复使用的火箭,将成本降到最低。如果能做到这一点,地球和火星之间的飞行可以每两年进行一次
 
马斯克表示,人类是生命的媒介,即使地球上发生了灾难——人为的或是自然的——看化石就可以知道此前发生过的物种灭绝,我们都有义务确保地球上的生物继续生存下去
 
如果能够在火星实现推进剂生产食品生产和发电,那么人类就可以在火星建立自给自足的城市,实现行星间穿行,这是实现人类意识长期存在所要做的最重要的事情之一。
 

玩电脑游戏的猩猩


昨天,马斯克发推帮自家公司Neuralink招人,访谈中他也提到了最近Neuralink的工作。
 
 
继脑机接口之后,马斯克想要造出一只通灵的猴子能打电脑游戏
 
Neuralink在寻找将传感器植入动物大脑,使动物之间可以产生互动,据马斯克介绍,Neuralink已经成功将无线传感器植入一只猩猩的大脑
 
据了解,植入大脑的传感器很小,并不会伤害动物
 
接下来,马斯克想让Neuralink在另一只猩猩的大脑中植入芯片,然后让这两只猩猩互动,主要是精神层面的互动。
 
马斯克想通过芯片植入让这两只猩猩的大脑能够玩模拟乒乓球游戏Pong.
 
 
「我们正在试图弄清楚的一件事是,是否可以让猩猩们在精神上互相打乒乓球 …… 那会很酷的。」
 
电影中有不少赋能大猩猩的桥段,但这似乎都不是一个好主意,虽然马斯克的想法是让大猩猩玩电脑游戏,并不会统治世界,但这也引起一些人的担心,只希望实验对象中没有叫「凯撒」的猩猩。
 
 

一字万金的男人


上周五,马斯克改了自己的推特简介,新简介只有一个词:Bitcoin.


还发了一条推文:回顾过去,这是不可避免的

推文发出后,比特币的价格迅速上涨,达到了37,803美元的峰值,在略微下跌之前,涨幅超过了17% . 目前 BTC 的价格为36,965美元



而上周,金融市场上最轰轰烈烈的是GameStop事件,Reddit网站上的散户大军「抱团」,靠着一只股票——GameStop,一家苦苦挣扎的视频游戏零售商,接连打败了多家大型投资机构。

在接受Clubhouse采访时,马斯克表示,我来晚了,但我支持比特币

然后他又转向了狗狗币,这个加密货币因为首富「突如其来」的关注上涨了3倍,周四达到了历史新高。


但马斯克觉得狗狗币很滑稽,他开玩笑说:「可以说,最有趣的结果,最具讽刺意味的结果是狗狗币将成为未来地球的货币」

在马斯克发表评论后,加密货币追踪软件 CoinDesk 立即显示狗狗币的价格有小幅下跌

马斯克代表一种未来


这是典型的马斯克意识流,时长约90分钟。谈话的节奏很激烈,也有一丝混乱,但当马斯克讲话时,人们似乎愿意倾听,因为你永远不知道事情的结局会怎样。
 
马斯克是除了名的精力旺盛,大脑总是充满了想法,精神从来没有休息过。
 
身体可以休息,想法永不止步。
 
某种意义上来说,马斯克的某些观点很哲学,代表着一种对未来的看法。
 
例如,他不止一次提到,他坚信世界只是「矩阵模拟」!人们也能进入大脑矢量空间。
 
时间要从2018年说起,那时马斯克参加了由喜剧演员Joe Rogan主持的The Joe Rogan Experience节目中,他比较全面的阐述了他自己的价值观,他坚信「我们活在模拟(simulation)中」
 
 
我们知道,这是一种很前卫的想发,但马斯克对此有更为古老的理论解释:宇宙已经存在了138亿年,而人类出现在地球上的历史才不到一万年,所以这段时间足够其他文明兴起。
 
马斯克根据的是宇宙历法,这是一种将宇宙年表可视化的方法,将宇宙目前的年龄138亿年缩放为一年,以帮助直观地进行科学评估。
 
在这个可视化中,大爆炸发生在1月1日午夜的开始,而现在的时刻映射到12月31日午夜前的结束在这个比例下,每秒有437.5年,每小时有175.5万年,每天有3780万年。
 
宇宙历的图形视图,包括一年的月份、十二月的天数和最后一分钟(来源:wikipedia)
 
这个概念被卡尔-萨根在他的《伊甸园之龙》(1977年)一书中和他的电视连续剧《宇宙》(Cosmos)中普及开来。

萨根继续用表面积来扩展比较,他解释说,如果把宇宙历法按比例放大到一个足球场的大小,那么「所有的人类历史将占据一个手掌大小的区域」
 
 
因此,马斯克相信,更古老的文明很有可能是我们的造物主,并将现实生活比作是过去数十年间游戏的进步。
 
这不是马斯克第一次分享这个想法,早在2016年的Recode’s annual Code Conference上,他就说过:
 
「鉴于我们明显处于与现实无法区分的游戏的轨道上,并且这些游戏可以在任何机顶盒或PC以及其它任何东西上播放,而且可能存在数十亿台这样的计算机或设备,那么我们在基础现实中的概率只有数十亿分之一。」
 
「40年前,我们有Pong,就是两个矩形和一个点。这就是游戏的开始。40年后,我们有了3D模拟,以及几百万人的在线游戏。而技术仍在发展,我们很快就会拥有VR和AR世界。」
 
 
虽然可以想象我们所有人都可能实际生活在一个巨大且先进的计算机游戏中,但物理学家们的确被这样的想法所吸引,并且从理论上讲,它至少可以算是一种可能性。
 
 
最近,他又谈及了他坚信不疑的「矩阵模拟假设」,他从压缩(降维)角度对机器学习进行有趣的物理学类比,认为物理模拟宇宙,最终你就会有感知能力
 
「神经网络主要是从现实中获取大量信息,很多来自无源光学方面,并创建矢量空间,本质上将大量光子压缩成矢量空间。」近日,他又在一组视频里谈到了这个问题。
 
人们是否能够进入大脑的矢量空间呢?
 
马斯克认为,「可以。」

他提到,运用压缩的类比方法,我们是可以进入大脑的矢量空间的。

大脑过滤很多信息,只留下相关的部分,这只是原始信息很小的一部分,但却可以根据矢量空间的决策做决定。

这实际上就是大规模的压缩与解压缩过程,就像物理学公式一样,因为公式就是对现实生活的压缩算法。
 
他还说到,如果我们对宇宙进行一个物理学意义上的模拟,就需要大规模的计算,如果有足够的时间,就会产生知觉。
 
这也并非空谈,著名的德雷克方程就可以作为理论依据,支持马斯克的想法。
 
德雷克公式又称「绿岸公式」,是用来推算银河系及可观测宇宙能与我们进行无线电通信的高智能文明数目。

由美国天文学家德雷克于1960年代在绿岸镇提出。通过估计我们银河系中可能存在的其他智慧文明的数量,计算出我们在宇宙中并不孤单的可能性。
 
 
不过,德雷克方程虽然简单,但却无法求解

该方程还有很多不确定项,比如发展出智慧生命的行星的比例;还有一些可能我们永远都不会知道,比如在被发现之前自我毁灭的比例。
 
看来马斯克并非只有金钱头脑,他的知识水平和思考维度也是非常广的。
 
最后不得不提一句,这次马斯克是在一款名为Clubhouse 的音频社交产品上进行的,很多知名风投、企业家和文娱界明星也入驻了这里,全是高质量用户,就像国内的知乎一样。

 



参考链接:

https://www.cnet.com/news/elon-musk-talks-mars-monkey-brain-implants-and-bitcoin-in-clubhouse-interview/
https://comicbook.com/irl/news/elon-musk-says-humans-on-mars-by-2026/