使用 Redis 的分布式锁，我们首先想到的是 setnx 命令，SET if Not Exists：
SETNX lockKey value EXPIRE lockKey 30
使用 jedis 的客户端代码如下：
if (jedis.setnx(lockKey, val) == 1) {
jedis.expire(lockKey, timeout);
}虽然这两个命令和前面算法描述中的一个 SET 命令执行效果相同，但却不是原子的。如果客户端在执行完 SETNX 后崩溃了，那么就没有机会执行 EXPIRE 了，导致它一直持有这个锁。
加锁和设置超时两个操作是分开的，并非原子操作。假设加锁成功，但是设置锁超时失败，那么该 lockKey 永不失效。
问题 1：为什么这个锁必须要设置一个过期时间？
当一个客户端获取锁成功之后，假如它崩溃了，或者它忘记释放锁，或者由于发生了网络分割（network partition）导致它再也无法和 Redis 节点通信了，那么它就会一直持有这个锁，而其它客户端永远无法获得锁了
问题 2：这个锁的有效时间设置多长比较合适？
前面这个算法中出现的锁的有效时间(lock validity time)，设置成多少合适呢？如果设置太短的话，锁就有可能在客户端完成对于共享资源的访问之前过期，从而失去保护；如果设置太长的话，一旦某个持有锁的客户端释放锁失败，那么就会导致所有其它客户端都无法获取锁，从而长时间内无法正常工作。看来真是个两难的问题。
Redis 客户端为了获取锁，向 Redis 节点发送如下命令：
SET lockKey requestId NX PX 30000
在 Java 中使用 jedis 包的调用方法是：
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime)
问题：为什么要设置一个随机字符串 requestId？如果没有会出现什么问题？
下面释放锁的时候给出答案。
如果按照如下方式加锁：
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;加锁之后，每次都会到 expireTime 之后才会释放锁，哪怕业务使用完这把锁了。所以更合理的做法是：
try{
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
} finally {
unlock(lockKey);
}
上面那个 unlock(lockKey)代码释放锁有什么问题？可能会出现释放别人的锁的问题。
有的同学可能会反驳：线程 A 获取了锁之后，它要是没有释放锁，这个时候别的线程假如线程 B、C……根本不可能获取到锁，何来释放别人锁之说？
如何解决这个问题：自己只能释放自己加的锁，不允许释放别人加的锁！
前面使用 set 命令加锁的时候，除了使用 lockKey 锁标识之外，还使用了一个 requestId，这个 requestId 的作用是什么呢？
requestId 是在释放锁的时候用的！！！
伪代码如下：
try{
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
} finally {
unlock(lockKey);
}
所以在释放锁的时候，先要获取到该锁的值（就是每个加锁线程自己设置的 requestId），然后判断跟之前自己设置的值是否相同，如果相同才允许删除锁，返回成功，如果不同，直接返回失败。
问题：为什么要设置一个随机字符串 requestId？如果没有会出现什么问题？
设置一个随机字符串 requestId 是必要的，它保证了一个客户端释放的锁必须是自己持有的那个锁。假如获取锁时 SET 的不是一个随机字符串，而是一个固定值，那么可能导致释放别人的锁。所以要保证 requestId 全局唯一。
if (jedis.get(lockKey).equals(requestId)) {
jedis.del(lockKey);
return true;
}
return false;显然，jedis.get(lockKey).equals(requestId) 这行代码包含了【获取该锁的值】，【判断是否是自己加的锁】，【删除锁】这三个操作，万一这三个操作中间的某个时刻出现阻塞
实际上，如果不是客户端 1 阻塞住了，而是出现了大的网络延迟，也有可能导致类似的执行序列发生。
问题的根源：锁的判断在客户端，但是锁的删除却在服务端！
正确的释放锁姿势——锁的判断和删除都在服务端（Redis），使用 lua 脚本保证原子性：
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end这段 Lua 脚本在执行的时候要把前面的 requestId 作为 ARGV[1]的值传进去，把 lockKey 作为 KEYS[1]的值传进去。
释放锁的操作为什么要使用 lua 脚本？
释放锁其实包含三步操作：‘GET’、判断和‘DEL’，用 Lua 脚本来实现能保证这三步的原子性。
如果客户端 1 请求锁成功了，但是由于业务处理、GC、操作系统等原因导致它处理时间过长，超过了锁的时间，这时候 Redis 会自动释放锁，这种情况可能导致问题：
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
//自动续期逻辑
}
}, 10000, TimeUnit.MILLISECONDS);这个机制在 Redisson 框架中已经实现，而且还有一个比较霸气的名字 watchdog（看门狗）：加锁时没有指定加锁时间时会启用 watchdog 机制，默认加锁 30 秒，每 10 秒钟检查一次，如果存在就重新设置 过期时间为 30 秒（即 30 秒之后它就不再续期了）
我们通常使用「Redis Cluster」或者「哨兵模式」这两种方式实现 Redis 的高可用，而这两种方式都是基于「主从架构数据同步复制」实现的，而 Redis 默认的主从复制是异步的。
前面铺垫的 Redis 锁在单点实例中是没有问题的，因为并没有涉及 Redis 的高可用部署架构细节。但是如果多实例的情况下会出现什么问题呢？比如：主从、或者使用了哨兵模式、或者 Redis cluster。Redis 的主从架构如下所示：
丢失数据场景：当网络发生脑裂（split-brain）或者 partitioned cluster 集群分裂为多数派与少数派，如果数据继续写入少数派的 Master，则当 Cluster 感知，并停止少数派 Master，或者重新选主时，则面临丢失刚才已写入少数派的数据
主从发生重新选导致分布式锁出现问题的场景：
WAIT numreplicas timeout
WAIT 命令作用：WAIT 命令阻塞当前客户端，直到所有先前的写入命令成功传输，并且由至少指定数量的副本（slave）确认。在主从、sentinel 和 Redis 群集故障转移中， WAIT 能够增强（仅仅是增强，但不是保证）数据的安全性。
官方文档：https://redis.io/commands/wait
针对上面的问题，Redis 之父 antirez 设计了 Redlock 算法，Redlock 的算法描述就放在 Redis 的官网上：
在 Redlock 之前，很多人对于分布式锁的实现都是基于单个 Redis 节点的。而 Redlock 是基于多个 Redis 节点（都是 Master）的一种实现。前面基于单 Redis 节点的算法是 Redlock 的基础。
Redlock 算法基于 N 个完全独立的 Redis 节点，客户端依次执行下面各个步骤，来完成获取锁的操作：
注意！！！redLock 会直接连接多个 Redis 主节点，不是通过集群机制连接的。
RedLock 的写与主从集群无关，直接操作的是所有主节点，所以才能避开主从故障切换时锁丢失的问题。
高并发场景下，当多个加锁线程并发抢锁时，可能导致脑裂，最终造成任何一个线程都无法抢到锁的情况。
值得强调的是，如果获取大部分锁失败，加锁线程应该尽可能快的释放（部分）已经获得了的锁。所以为了让锁能够再次被获得就没有必要等待 key 过期（然而如果发生了网络分区导致客户端无法再与 Redis 实例交互，那么就必须等待 key 过期才能重新抢到锁）。
Redlock 算法释放锁的过程比较简单：客户端向所有 Redis 节点发起释放锁的操作，不管这些节点当时在获取锁的时候成功与否。
问题 1：为什么要在多个实例上加锁？
本质上为了容错，部分实例异常宕机，剩余实例只要超过 N/2+1 依旧可用。多个实例节点，实际上构建了一个分布式锁系统。分布式系统中，总会有异常节点，所以需要考虑异常节点达到多少个，也不会影响整个系统的正确性。（可以参考一下拜占庭将军问题的分析）
问题 2：为什么步骤 3 加锁成功之后，还要计算加锁的累计耗时？
因为加锁操作的针对的是分布式中的多个节点，所以耗时肯定是比单个实例耗时更久，至少需要 N/2+1 个网络来回，还要考虑网络延迟、丢包、超时等情况发生，网络请求次数越多，异常的概率越大。所以即使 N/2+1 个节点加锁成功，但如果加锁的累计耗时已经超过了锁的过期时间，那么此时的锁已经没有意义了。
问题 3：为什么释放锁，要操作所有节点，对所有节点都释放锁？
因为当对某一个 Redis 节点加锁时，可能因为网络原因导致加锁“失败”。注意这个“失败”，指的是 Redis 节点实际已经加锁成功了，但是返回的结果因为网络延迟并没有传到加锁的线程，被加锁线程丢弃了，加锁线程误以为没有成功，于是加锁线程去尝试下一个节点了。
所以释放锁的时候，不管以前有没有加锁成功，都要释放所有节点的锁，以保证清除节点上述图中发生的情况导致残留的锁。
假设 Rodlock 算法中的 Redis 发生了崩溃-恢复，那么锁的安全性将无法保证。假设加锁线程在 5 个实例中对其中 3 个加锁成功，获得了这把分布式锁，这个时候 3 个实例中有一个实例被重启了。重启后的实例将丢失其中的锁信息，这个时候另一个加锁线程可以对这个实例加锁成功，此时两个线程同时持有分布式锁。锁的安全性被破坏。
fsync=always，但此时 Redis 的性能将大大打折扣。
为了保证这一点，我们只需要让一个崩溃时间、不可用时间（实例崩溃后存在的锁的所有 key 所需的时间）比最大 TTL 还要长的实例变成非法和自动释放的。
如果不配置 Redis 持久化，那么只能使用延迟重启保证锁的安全性。
结论：为了保证 Redlock 算法的安全性，有如下两种手段
fsync=always，性能大大降低Redis 之父 Antirez 实现 Redlock 算法之后。有一天，Martin Kleppmann 写了一篇 blog，分析了 Redlock 在安全性上存在的一些问题。然后 Redis 的作者立即写了一篇 blog 来反驳 Martin 的分析。但 Martin 表示仍然坚持原来的观点。随后，这个问题在 Twitter 和 Hacker News 上引发了激烈的讨论，很多分布式系统的专家都参与其中。
Martin Kleppmann 在 2016-02-08 这一天发表了一篇 blog，名字叫“How to do distributed locking”，地址如下：
Martin 在这篇文章中谈及了分布式系统的很多基础性的问题（特别是分布式计算的异步模型），对分布式系统的从业者来说非常值得一读。这篇文章大体可以分为两大部分：
首先我们讨论一下前半部分的关键点。Martin 给出了下面这样一份时序图：
初看上去，有人可能会说，既然客户端 1 从 GC pause 中恢复过来以后不知道自己持有的锁已经过期了，那么它可以在访问共享资源之前先判断一下锁是否过期。但仔细想想，这丝毫也没有帮助。因为 GC pause 可能发生在任意时刻，也许恰好在判断完之后。
也有人会说，如果客户端使用没有 GC 的语言来实现，是不是就没有这个问题呢？Martin 指出，系统环境太复杂，仍然有很多原因导致进程的 pause，比如虚存造成的缺页故障(page fault)，再比如 CPU 资源的竞争。即使不考虑进程 pause 的情况，网络延迟也仍然会造成类似的结果。
总结起来就是说，即使锁服务本身是没有问题的，而仅仅是客户端有长时间的 pause 或网络延迟，仍然会造成两个客户端同时访问共享资源的冲突情况发生。而这种情况其实就是我们在前面已经提出来的“客户端长期阻塞导致锁过期”的那个疑问。
那怎么解决这个问题呢？Martin 给出了一种方法，称为 fencing token。fencing token 是一个单调递增的数字，当客户端成功获取锁的时候它随同锁一起返回给客户端。而客户端访问共享资源的时候带着这个 fencing token，这样提供共享资源的服务就能根据它进行检查，拒绝掉延迟到来的访问请求（避免了冲突）。如下图：
（问题：考虑网络延迟导致 33 号 token 比 34 号先到的情景）
Martin 在文中构造了一些事件序列，能够让 Redlock 失效（两个客户端同时持有锁）。为了说明 Redlock 对系统记时(timing)的过分依赖，他首先给出了下面的一个例子（还是假设有 5 个 Redis 节点 A, B, C, D, E）：
上面这种情况之所以有可能发生，本质上是因为Redlock 的安全性(safety property)对系统的时钟有比较强的依赖，一旦系统的时钟变得不准确，算法的安全性也就保证不了了。Martin 在这里其实是要指出分布式算法研究中的一些基础性问题，或者说一些常识问题，即好的分布式算法应该基于异步模型(asynchronous model)，算法的安全性不应该依赖于任何记时假设(timing assumption)。在异步模型中：进程可能 pause 任意长的时间，消息可能在网络中延迟任意长的时间，甚至丢失，系统时钟也可能以任意方式出错。一个好的分布式算法，这些因素不应该影响它的安全性(safety property)，只可能影响到它的活性(liveness property)，也就是说，即使在非常极端的情况下（比如系统时钟严重错误），算法顶多是不能在有限的时间内给出结果而已，而不应该给出错误的结果。这样的算法在现实中是存在的，像比较著名的Paxos，或 Raft。但显然按这个标准的话，Redlock 的安全性级别是达不到的。
在 Martin 的这篇文章中，还有一个很有见地的观点，就是对锁的用途的区分。他把锁的用途分为两种：
最后，Martin 得出了如下的结论：
Martin 对 Redlock 算法的形容是：
neither fish nor fowl （不伦不类）
【其它疑问】
N 个 Redis 节点中如果有节点发生崩溃重启，会对锁的安全性有影响的。具体的影响程度跟 Redis 对数据的持久化程度有关。参考上面的“崩溃恢复（AOF 持久化）对 Redlock 算法影响”分析。
【备注】在默认情况下，Redis 的 AOF 持久化方式是每秒写一次磁盘（即执行 fsync），因此最坏情况下可能丢失 1 秒的数据。为了尽可能不丢数据，Redis 允许设置成每次修改数据都进行 fsync，但这会降低性能。当然，即使执行了 fsync 也仍然有可能丢失数据（这取决于系统而不是 Redis 的实现）。所以，上面分析的由于节点重启引发的锁失效问题，总是有可能出现的。
Redis 之父 antirez 提出了延迟重启(delayed restarts)的概念。也就是说，一个节点崩溃后，先不立即重启它，而是等待一段时间再重启，这段时间应该大于锁的有效时间(lock validity time)。这样的话，这个节点在重启前所参与的锁都会过期，它在重启后就不会对现有的锁造成影响。
Redlock 的安全性(safety property)对系统的时钟有比较强的依赖，一旦系统的时钟变得不准确，算法的安全性也就保证不了了。
结论：Redis 的过期时间是依赖系统时钟的，如果时钟漂移过大时会影响到过期时间的计算。
为什么系统时钟会存在漂移呢？先简单说下系统时间，linux 提供了两个系统时间：clock realtime 和 clock monotonic
最理想的情况是：所有系统的时钟都时时刻刻和 NTP 服务器保持同步，但这显然是不可能的。
clock realtime 可以被人为修改，在实现分布式锁时，不应该使用 clock realtime。不过很可惜，Redis 使用的就是这个时间，Redis 5.0 使用的还是 clock realtime。Antirez 说过后面会改成 clock monotonic 的。也就是说，人为修改 Redis 服务器的时间，就能让 Redis 出问题了。
什么情况下会发生时钟变迁？
RedLock 的核心价值，在于多数派思想。相比于基于单点 Redis 的锁服务，RedLock 解决了锁数据写入时多份的问题，从而可以克服单点故障下的数据一致性问题。在继承自基于单点的 Redis 锁服务缺陷（解锁不具备原子性；锁服务、调用方、资源方缺乏确认机制）的基础上，其核心的问题为：缺乏锁数据丢失的识别和感知机制。
RedLock 中的每台 Redis，充当的仍旧只是存储锁数据的功能，每台 Redis 之间各自独立，单台 Redis 缺乏全局的信息，自然也不知道自己的锁数据是否是完整的。在单台 Redis 数据的不完整的前提下，没有分布式共识机制，使得在各种分布式环境的典型场景下（结点故障、网络丢包、网络乱序），没有完整数据但参与决策，从而破坏数据一致性。
使用 ShedLock 需要在 MySQL 数据库创建一张加锁用的表：
CREATE TABLE shedlock
(
name VARCHAR(64),
lock_until TIMESTAMP(3) NULL,
locked_at TIMESTAMP(3) NULL,
locked_by VARCHAR(255),
PRIMARY KEY (name)
)INSERT INTO shedlock
(name, lock_until, locked_at, locked_by)
VALUES
(锁名字, 当前时间+最多锁多久, 当前时间, 主机名)UPDATE shedlock
SET lock_until = 当前时间+最多锁多久,
locked_at = 当前时间,
locked_by = 主机名 WHERE name = 锁名字 AND lock_until <= 当前时间UPDATE shedlock
SET lock_until = lockTime WHERE name = 锁名字ZooKeeper 的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做 Znode。Znode 分为四种类型：
1 . 持久节点 （PERSISTENT）
默认的节点类型。创建节点的客户端与 ZooKeeper 断开连接后，该节点依旧存在 。
2 . 持久节点顺序节点（PERSISTENT_SEQUENTIAL）
所谓顺序节点，就是在创建节点时，ZooKeeper 根据创建的顺序给该节点名称进行编号：
3 . 临时节点（EPHEMERAL）
和持久节点相反，当创建节点的客户端与 ZooKeeper 断开连接后，临时节点会被删除：
4 . 临时顺序节点（EPHEMERAL_SEQUENTIAL）【使用该类型节点实现分布式锁】
顾名思义，临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，ZooKeeper 根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与 ZooKeeper 断开连接后，临时节点会被删除。
ZooKeeper 集群和客户端通过长连接维护一个 session，当客户端试图创建/lock 节点的时候，发现它已经存在了，这时候创建失败，但客户端不一定就此返回获取锁失败。客户端可以进入一种等待状态，等待当/lock 节点被删除的时候，ZooKeeper 通过 watch 机制通知它，这样它就可以继续完成创建操作（获取锁）。这可以让分布式锁在客户端用起来就像一个本地的锁一样：加锁失败就阻塞住，直到获取到锁为止。这样的特性 Redis 的 Redlock 就无法实现。
ZooKeeper 不依赖全局时间，它使用 zab 协议实现分布式共识算法，不存在该问题。
ZooKeeper 不依赖有效时间，它依靠心跳维持锁的占用状态，不存在该问题。
看起来这个锁相当完美，没有 Redlock 过期时间的问题，而且能在需要的时候让锁自动释放。但仔细考察的话，并不尽然。客户端可以删除锁，Z**ooKeeper 服务器也可以删除锁，**会引发什么问题。
实际上，每个客户端都与 ZooKeeper 的某台服务器维护着一个 Session，这个 Session 依赖定期的心跳(heartbeat)来维持。如果 ZooKeeper 长时间收不到客户端的心跳（这个时间称为 Sesion 的过期时间），那么它就认为 Session 过期了，通过这个 Session 所创建的所有的 ephemeral 类型的 znode 节点都会被自动删除。
这个场景下，客户端 1 和客户端 2 在一段窗口时间内同时获取到锁。
结论：使用 ZooKeeper 的临时节点实现的分布式锁，它的锁安全期是在客户端取得锁之后到 zk 服务器会话超时的阈值（跨机房部署很容易出现）的时间之间。它无法设置占用分布式锁的时间，何时 zk 服务器会删除锁是不可预知的，所以这种方式它比较适合一些客户端获取到锁之后能够快速处理完毕的场景。
另外一种使用 zk 作分布式锁的实现方式：不使用临时节点，而是使用持久节点加锁，把 zk 集群当做一个 MySQL、或者一个单机版的 Redis，加锁的时候存储锁的到期时间，这种方案把锁的删除、判断过期这两个职责交给客户端处理。（当做一个可以容错的 MySQL，性能问题！）
总结一下 ZooKeeper 分布式锁：
ZooKeeper 实现的分布式锁，性能并不太高。为啥呢？
因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。大家知道，ZK 中创建和删除节点只能通过 Leader 服务器来执行，然后 Leader 服务器还需要将数据同步不到所有的 Follower 机器上，这样频繁的网络通信，性能的短板是非常突出的。
总之，在高性能，高并发的场景下，不建议使用 ZooKeeper 的分布式锁。而由于 ZooKeeper 的高可用特性，所以在并发量不是太高的场景，推荐使用 ZooKeeper 的分布式锁。
小结一下，基于 ZooKeeper 的锁和基于 Redis 的锁相比在实现特性上有两个不同：
提到分布式锁，就不能不提 Google 的 Chubby。
Chubby 是 Google 内部使用的分布式锁服务，有点类似于 ZooKeeper，但也存在很多差异。Chubby 对外公开的资料，主要是一篇论文，叫做“The Chubby lock service for loosely-coupled distributed systems”，下载地址如下：
另外，YouTube 上有一个的讲 Chubby 的 talk，也很不错，播放地址：
a process holding a lock L may issue a request R, but then fail. Another process may ac- quire L and perform some action before R arrives at its destination. If R later arrives, it may be acted on without the protection of L, and potentially on inconsistent data.
（译文：一个进程持有锁 L，发起了请求 R，但是请求失败了。另一个进程获得了锁 L 并在请求 R 到达目的方之前执行了一些动作。如果后来请求 R 到达了，它就有可能在没有锁 L 保护的情况下进行操作，带来数据不一致的潜在风险。）
这跟前面 Martin 的分析大同小异。
sequencer：客户端拿到 sequencer 之后，在操作资源的时候把它传给资源服务器。然后，资源服务器负责对 sequencer 的有效性进行检查。检查可以有两种方式：
锁延期机制：当然，如果由于兼容的原因，资源服务本身不容易修改，那么 Chubby 还提供了一种机制：
可见，为了应对锁失效问题，Chubby 提供的两种处理方式：CheckSequencer()检查与上次最新的 sequencer 对比、lock-delay，它们对于安全性的保证是从强到弱的。而且，这些处理方式本身都没有保证提供绝对的正确性(correctness)。但是，Chubby 确实提供了单调递增的 lock generation number，这就允许资源服务器在需要的时候，利用它提供更强的安全性保障。
总结起来，Chubby 引入了资源方和锁服务的验证，来避免了锁服务本身孤立地做预防死锁机制而导致的破坏锁安全性的风险。同时依靠 Session 来维持锁的持有状态，在正常情况下，客户端可以持有锁任意长的时间，这可以确保它做完所有需要的资源访问操作之后再释放锁。这避免了基于 Redis 的锁对于有效时间(lock validity time)到底设置多长的两难问题。
需要考虑的问题：我们的业务对极端情况的容忍度，为了一把绝对安全的分布式锁导致过度设计，引入的复杂性和得到的收益是否值得。
本文由哈喽比特于2年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/-N4x6EkxwAYDGdJhwvmZLw
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道，荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦（ASML）CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候，抖音悄然上线了一款名为“青桃”的 App，Slogan 为“看见你的热爱”，根据应用介绍可知，“青桃”是一个属于年轻人的兴趣知识视频平台，由抖音官方出品的中长视频关联版本，整体风格有些类似B站。
日前，威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”，同时，他发文表示：中国汽车普及率低于非洲国家尼日利亚，每百户家庭仅17户有车。意大利世界排名第一，每十户中九户有车。
近日，一项新的研究发现，维生素 C 和 E 等抗氧化剂会激活一种机制，刺激癌症肿瘤中新血管的生长，帮助它们生长和扩散。
据媒体援引消息人士报道，苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后，3D系统一度大涨超10%，不过截至周三收盘，该股涨幅回落至2%以内。
9月2日，坐拥千万粉丝的网红主播“秀才”账号被封禁，在社交媒体平台上引发热议。平台相关负责人表示，“秀才”账号违反平台相关规定，已封禁。据知情人士透露，秀才近期被举报存在违法行为，这可能是他被封禁的部分原因。据悉，“秀才”年龄39岁，是安徽省亳州市蒙城县人，抖音网红，粉丝数量超1200万。他曾被称为“中老年...
9月3日消息，亚马逊的一些股东，包括持有该公司股票的一家养老基金，日前对亚马逊、其创始人贝索斯和其董事会提起诉讼，指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息，为推广自家应用，苹果现推出了一个名为“Apps by Apple”的网站，展示了苹果为旗下产品（如 iPhone、iPad、Apple Watch、Mac 和 Apple TV）开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价，引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金（Future Fund）管理合伙人加里·布莱克发帖称，降价是一种“短期麻醉剂”，会让潜在客户等待进一步降价。
据外媒9月2日报道，荷兰半导体设备制造商阿斯麦称，尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效，但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日，根据美国证券交易委员会的文件显示，苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元（约 4.65 亿元人民币）。用于在 2023-2025 年期间，发射卫星，进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道，马斯克旗下社交平台𝕏（推特）日前调整了隐私政策，允许 𝕏 使用用户发布的信息来训练其人工智能（AI）模型。新的隐私政策将于 9 月 29 日生效。新政策规定，𝕏可能会使用所收集到的平台信息和公开可用的信息，来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日，荣耀CEO赵明在采访中谈及华为手机回归时表示，替老同事们高兴，觉得手机行业，由于华为的回归，让竞争充满了更多的可能性和更多的魅力，对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能（AI）系统，该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日，非营利组织纽约真菌学会（NYMS）发出警告，表示亚马逊为代表的电商平台上，充斥着各种AI生成的蘑菇觅食科普书籍，其中存在诸多错误。
社交媒体平台𝕏（原推特）新隐私政策提到：“在您同意的情况下，我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上，各大企业都带来了最新的理念和产品，而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品，具体内容为：“以我对我‘子公司’的了解，我认为 iPhone 15 跟 iPhone 14 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
