首页 文章 精选 留言 我的

精选列表

搜索[思维链]，共10000篇文章
优秀的个人博客,低调大师

火花思维三面：说说Redis分布式锁是如何实现的！

前言 近来，分布式的问题被广泛提及，比如分布式事务、分布式框架、ZooKeeper、SpringCloud等等。本文先回顾锁的概念，再介绍分布式锁，以及如何用Redis来实现分布式锁。 一、锁的基本了解 首先，回顾一下我们工作学习中的锁的概念。 为什么要先讲锁再讲分布式锁呢？ 我们都清楚，锁的作用是要解决多线程对共享资源的访问而产生的线程安全问题，而在平时生活中用到锁的情况其实并不多，可能有些朋友对锁的概念和一些基本的使用不是很清楚，所以我们先看锁，再深入介绍分布式锁。 Redis分布式锁面试题答案地址：Redis分布式面试题 通过一个卖票的小案例来看，比如大家去抢dota2 ti9门票，如果不加锁的话会出现什么问题？此时代码如下： **代码分析：**这里有8张ti9门票，设置了10个线程（也就是模拟10个人）去并发抢票，如果抢成功了显示成功，抢失败的话显示失败。按理说应该有8个人抢成功了，2个人抢失败，下面来看运行结果： 我们发现运行结果和预期的情况不一致，居然10个人都买到了票，也就是说出现了线程安全的问题，那么是什么原因导致的呢？ 原因就是多个线程之间产生了时间差。 如图所示，只剩一张票了，但是两个线程都读到的票余量是1，也就是说线程B还没有等到线程A改库存就已经抢票成功了。 怎么解决呢？想必大家都知道，加个synchronized关键字就可以了，在一个线程进行reduce方法的时候，其他线程则阻塞在等待队列中，这样就不会发生多个线程对共享变量的竞争问题。 举个例子 比如我们去健身房健身，如果好多人同时用一台机器，同时在一台跑步机上跑步，就会发生很大的问题，大家会打得不可开交。如果我们加一把锁在健身房门口，只有拿到锁的钥匙的人才可以进去锻炼，其他人在门外等候，这样就可以避免大家对健身器材的竞争。代码如下： 运行结果： 果不其然，结果有两个人没有成功抢到票，看来我们的目地达成了。 二、锁的性能优化 2.1 缩短锁的持有时间 事实上，按照我们对日常生活的理解，不可能整个健身房只有一个人在运动。所以我们只需要对某一台机器加锁就可以了，比如一个人在跑步，另一个人可以去做其他的运动。 对于票务系统来说，我们只需要对库存的修改操作的代码加锁就可以了，别的代码还是可以并行进行，这样会大大减少锁的持有时间，代码修改如下： 这样做的目的是充分利用cpu的资源，提高代码的执行效率。 这里我们对两种方式的时间做个打印： 果然，只对部分代码加锁会大大提供代码的执行效率。 所以，在解决了线程安全的问题后，我们还要考虑到加锁之后的代码执行效率问题。 2.2 减少锁的粒度 举个例子，有两场电影，分别是最近刚上映的魔童哪吒和蜘蛛侠，我们模拟一个支付购买的过程，让方法等待，加了一个CountDownLatch的await方法，运行结果如下： 执行结果： 魔童哪吒的剩余票数为：20 我们发现买哪吒票的时候阻塞会影响蜘蛛侠票的购买，而实际上，这两场电影之间是相互独立的，所以我们需要减少锁的粒度，将movie整个对象的锁变为两个全局变量的锁，修改代码如下： 执行结果： 魔童哪吒的剩余票数为：20 蜘蛛侠的剩余票数为：100 现在两场电影的购票不会互相影响了，这就是第二个优化锁的方式：减少锁的粒度。顺便提一句，Java并发包里的ConcurrentHashMap就是把一把大锁变成了16把小锁，通过分段锁的方式达到高效的并发安全。 2.3 锁分离 锁分离就是常说的读写分离，我们把锁分成读锁和写锁，读的锁不需要阻塞，而写的锁要考虑并发问题。 三、锁的种类 公平锁： ReentrantLock 非公平锁： Synchronized、ReentrantLock、cas 悲观锁： Synchronized 乐观锁：cas 独享锁：Synchronized、ReentrantLock 共享锁：Semaphore 这里就不一一讲述每一种锁的概念了，大家可以自己学习，锁还可以按照偏向锁、轻量级锁、重量级锁来分类。 四、Redis分布式锁 了解了锁的基本概念和锁的优化后，重点介绍分布式锁的概念。 上图所示是我们搭建的分布式环境，有三个购票项目，对应一个库存，每一个系统会有多个线程，和上文一样，对库存的修改操作加上锁，能不能保证这6个线程的线程安全呢？ 当然是不能的，因为每一个购票系统都有各自的JVM进程，互相独立，所以加synchronized只能保证一个系统的线程安全，并不能保证分布式的线程安全。 所以需要对于三个系统都是公共的一个中间件来解决这个问题。 这里我们选择Redis来作为分布式锁，多个系统在Redis中set同一个key，只有key不存在的时候，才能设置成功，并且该key会对应其中一个系统的唯一标识，当该系统访问资源结束后，将key删除，则达到了释放锁的目的。 4.1 分布式锁需要注意哪些点 1）互斥性 在任意时刻只有一个客户端可以获取锁。 这个很容易理解，所有的系统中只能有一个系统持有锁。 2）防死锁 假如一个客户端在持有锁的时候崩溃了，没有释放锁，那么别的客户端无法获得锁，则会造成死锁，所以要保证客户端一定会释放锁。 Redis中我们可以设置锁的过期时间来保证不会发生死锁。 3）持锁人解锁 解铃还须系铃人，加锁和解锁必须是同一个客户端，客户端A的线程加的锁必须是客户端A的线程来解锁，客户端不能解开别的客户端的锁。 4）可重入 当一个客户端获取对象锁之后，这个客户端可以再次获取这个对象上的锁。 4.2 Redis分布式锁流程 Redis分布式锁的具体流程： 1）首先利用Redis缓存的性质在Redis中设置一个key-value形式的键值对，key就是锁的名称，然后客户端的多个线程去竞争锁，竞争成功的话将value设为客户端的唯一标识。Java学习圈子:14 201 9 080 2）竞争到锁的客户端要做两件事： 设置锁的有效时间 目的是防死锁 （非常关键） 需要根据业务需要，不断的压力测试来决定有效期的长短。 分配客户端的唯一标识，目的是保证持锁人解锁（非常重要） 所以这里的value就设置成唯一标识(比如uuid)。 3）访问共享资源 4）释放锁，释放锁有两种方式，第一种是有效期结束后自动释放锁，第二种是先根据唯一标识判断自己是否有释放锁的权限，如果标识正确则释放锁。 4.3 加锁和解锁 4.3.1 加锁 1）setnx命令加锁 set if not exists 我们会用到Redis的命令setnx，setnx的含义就是只有锁不存在的情况下才会设置成功。 2）设置锁的有效时间，防止死锁 expire 加锁需要两步操作，思考一下会有什么问题吗？ 假如我们加锁完之后客户端突然挂了呢？那么这个锁就会成为一个没有有效期的锁，接着就可能发生死锁。虽然这种情况发生的概率很小，但是一旦出现问题会很严重，所以我们也要把这两步合为一步。 幸运的是，Redis3.0已经把这两个指令合在一起成为一个新的指令。 来看jedis的官方文档中的源码： 这就是我们想要的！ 4.3.2 解锁 检查是否自己持有锁（判断唯一标识）； 删除锁。 解锁也是两步，同样也要保证解锁的原子性，把两步合为一步。 这就无法借助于Redis了，只能依靠Lua脚本来实现。 这就是一段判断是否自己持有锁并释放锁的Lua脚本。 为什么Lua脚本是原子性呢？因为Lua脚本是jedis用eval()函数执行的，如果执行则会全部执行完成。 五、Redis分布式锁代码实现 用一个上下文全局变量来记录持有锁的人的uuid，解锁的时候需要将该uuid作为参数传入Lua脚本中，来判断是否可以解锁。 要记录当前线程，来实现分布式锁的重入性，如果是当前线程持有锁的话，也属于加锁成功。 用eval函数来执行Lua脚本，保证解锁时的原子性。 六、分布式锁的对比 6.1 基于数据库的分布式锁 1）实现方式 获取锁的时候插入一条数据，解锁时删除数据。 2）缺点 数据库如果挂掉会导致业务系统不可用。 无法设置过期时间，会造成死锁。 6.2 基于zookeeper的分布式锁 1）实现方式 加锁时在指定节点的目录下创建一个新节点，释放锁的时候删除这个临时节点。因为有心跳检测的存在，所以不会发生死锁，更加安全。 2）缺点 性能一般，没有Redis高效。 所以： 从性能角度： Redis > zookeeper > 数据库 从可靠性（安全）性角度： zookeeper > Redis > 数据库 七、总结 本文从锁的基本概念出发，提出多线程访问共享资源会出现的线程安全问题，然后通过加锁的方式去解决线程安全的问题，这个方法会性能会下降，需要通过：缩短锁的持有时间、减小锁的粒度、锁分离三种方式去优化锁。 更多Java面试资料共享地址：面试题资料合集 之后介绍了分布式锁的4个特点： 互斥性 防死锁 加锁人解锁 可重入性 然后用Redis实现了分布式锁，加锁的时候用到了Redis的命令去加锁，解锁的时候则借助了Lua脚本来保证原子性。 最后对比了三种分布式锁的优缺点和使用场景。
2021-07-23
优秀的个人博客,低调大师

从技术思维角度聊一聊『程序员』摆地摊的正确姿势

有人说程序员这个职业，三年升高工，七年做架构，十年送外卖。对此虽然我也曾非常认可，但现在我可以前瞻性（马后炮）地说四个字，杞人忧天！目光肤浅！正所谓天生我材必有用，用完再把外卖送，现在，新的风口——万亿【烟火经济】来了，除了送外卖我们又多了个新选择：摆地摊！一个人一辈子只有那么几次机会可能实现财务自由，机遇稍纵即逝，一定要牢牢把握住。所以，今天我们来严肃认真地聊一聊程序员摆地摊的正确姿势。 01 技术储备 程序员是谁？ 一群志存高远立志要靠技术改变世界的人！ 一群囊萤映雪时刻站在技术风口的人！ 一群镂月裁云面试可以造火箭的人！ 一群居安思危28岁就时刻焦虑未来的人！ 正所谓打铁还需自身硬，在我们决定投身摆摊大业之前，一定要认清自己找准定位，了解自己在摆摊行业能够达到什么级别？根据程序员这些年来面试招聘的经验我可以给大家一点参考，我认为一个合格的P6级别地摊员应该具备改变全球宏观经济走向的能力，具有将各类地摊货抽丝剥茧再从0到1的能力。 P6级别地摊员面试题举例： 请说说摆地摊背后的经济学原理。 画一张从家到摆地摊地点的地图，0表示可以走，1表示不可以走，请编写一个程序，用合适的算法找到最短路线。 摆地摊可以有很多工具：一块布、地摊三轮车、私家车后备箱、五菱宏光、蓝翔挖掘机，请对比一些这些工具的优缺点？并讲讲你最熟悉的一个工具的运行流程。 摆地摊的过程中，亿级流量过来怎么办？高并发怎么办？高可用怎么做？ 这几道题熟悉吗？如果你答不出来，建议你再回去多看看书，推荐几本： 《摆摊人员的自我修养》《摆摊的二十三种设计模式》《深入源零件，了解摆摊车的工作原理》 除此之外，还需要多读一读国外大佬的英文原版著作，特别是一些诺贝尔经济学奖大佬的，比如凯恩斯的《就业、利息和货币通论》、约瑟夫·熊彼特的《经济发展理论》、萨缪尔森的《经济学》、西蒙·库兹涅茨的《各国的经济增长》等。 “你先回去吧，正常我们会在两个星期左右给你答复。” “码大叔，恭喜你通过了我们的面试，你接下来的工作就是和我一起搬羊肉串” 你看，原来所谓的合适，只是你能不能和我一起吹个很爽的牛，然后干件平凡的事。 我是摆地摊的，但是我就想和你聊一聊八千里路云和月！ 02 找准方向 做好技术储备认清自己后，接下来就是找准方向，好的方向是成功的一半。很多人也想去摆地摊，但无奈不知道该做什么，导致自己始终迈不出摆摊的第一步。这件事对于程序员就比较简单，无非三个选择。 选择一：技术导向型创业 大多数程序员是有技术情怀的，通过自己的技术去改变或影响一批人，从而带来自己的商业价值。所以如果选择这个方向的摆摊，完全不需要考虑，看自己擅长什么，可以去制造摆摊车，可以去制造一些小商品，取决于自身能力。 选择二：技术入股型创业 做好你技术分内的事吧！用程序员的专业术语来说，就是单一职责，解耦合。至于什么方向交给你的合伙人，让专业的人做专业的事！ 选择三：加入一家牛逼的摆摊公司 我们需要做的就是做好业务抽象和建模，设计一套通用的摆地摊架构，卖什么不重要，重要的是我们什么都能卖。具体卖什么由产品经理和运营大佬去商量。这个时候选择一个好的团队很重要，我们团队就很好，就有一个资深产品经理，可以和程序员打成一片。 “那边两个人在做什么” “穿格子的是程序员，还有一个是产品经理。产品经理说摆地摊一定要注重用户体验，简化用户的操作。举个栗子假如我们的地摊货是手机壳，你不能让用户挑来逃去这样体验太差，效率也很低。你得能根据用户的心情自动变换颜色、背景，说完两人就开打了，打了一年多没停手。” 你看，对于程序员，选择是如此简单！ 困住我们手脚的，是顾虑！ 早已成年的我们，需要的可能是那么一次年少轻狂、肆无忌惮！ 03 微服务架构 首先，我们来看一张图： 看出什么问题没有？ 对，太明显了，这还是传统的摆地摊方式，最初级的单体地摊架构！这样使得地摊服务过于臃肿，全部集中在一个人身上，不利于管理；容错性差，一旦出点小问题，就会导致整个服务宕机。比如用户要用支付宝付款，结果手机没电了，你得等着他呀，其他客户怎么办？而且这样也不利于扩展，摆摊事业做大了怎么支撑？还有一个最大的问题，就是它不符合当今地摊行业的潮流， 所以，最正确的姿势应该是：拆！将整个地摊的架构微服务化。你别管它合不合适，这都2200年了，顺应潮流、顺流而上，你才不会被潮流淹没，不会被这个时代所抛弃。不然你只能回去继续写你低端的代码，干不了地摊员。 如上图所示，微服务化后就成为上面这样的，有人管销售，有人管结账，有人管商品，有人管库存，有人管开神车。这样拆下来，它使整个地摊的分工更加明确，责任更加清晰，每个人专心负责为其他人提供最专业的服务。 独立的可扩展性，每个微服务都可以独立进行横向或纵向扩展；比如上面提到的收银服务慢，再来一个人呗； 独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务；比如五菱宏光要升级成蓝翔挖掘机，升级就是了。 易维护性，每个微服务的只专注于完成自己业务范畴的事情；你不用同时担心库存够不够，钱会不会算错等等，每个人专注自己的一部分。 故障和资源的隔离性，在系统中出现不好的资源操作行为时，例如销售忙到瘫痪导致内存泄露，后续的结账还可以继续进行。 等等 术业有专攻，专业的人做专业的事，你看我们像不像一个个微服务？当我们夸夸其谈其先进性的时候，以为自己走在技术前沿的时候，以为自己支撑了一整个服务集群的时候，我们可能已经忘了，这个事情我们已经做了很久很久，这个地方我们已经待了很久很久。我们以为自己是一个独立的服务可以独立地运作，却从来没有想过脱离了这个服务体系的时候，其实，一无是处！ 单体应用，还是微服务？ 我们需要什么？ 这个世界需要我们什么？ 04 放眼未来 作为具有程序员背景的地摊员，我们的目光不能局限于当下，要充分考虑未来地摊事业发展对当前架构的依赖及可能存在的风险，提前做好风险预案。比如： 万一有亿级客户流量来访问我们的地摊呢？我们该如何做好流量控制？熔断降级？ 要不要再准备一队地摊员做好主备和负载均衡等？ 我们的地摊货要不要分库分表呢？ 要不要做读写分离，专门安排人员负责客户询价、地摊货咨询等？ 要不要引入排队机制？要不要给他们发个令牌才能来我们的地摊呢？ 等等 还有很关键的一点，地摊事业未来会不会遭遇某些人的封禁或者打压，比如： 万一有人说地摊是他们国家的物质文化遗产，是他们发明的呢？ 万一有人觉得红火的地摊事业影响到了他们的安全，要将我们列入实体清单进行管制呢？ 地摊，作为一个炙手可热的风口产业，一个充满无限可能的产业，让我们一起去摆摊吧。虽然我的想象力不足以想象地摊业的未来，但我的心里有火，眼里有光。即将投入地摊事业的程序员们，请接受我的祝福, 奔涌吧，地摊员 我们在同一条奔涌的河流。 它是一个地摊， 它是一个机会， 它是大千世界， 它是我们的内心。 梦想还是要有的，万一实现了呢？ 梦想还是要有的，至少这样当我们想努力拼搏一把的时候，知道该往哪个方向！ 写着写着我忽然想起来，这个摆地摊的架构好像还有优化空间，要不要再上个中台系统呢？ 得好好考虑考虑一下！ 我的其他文章这些Java8官方挖的坑，你踩过几个？Try-Catch包裹的代码异常后，竟然导致了产线事务回滚！Redis 6.0 新特性-多线程连环13问！报告老板，微服务高可用神器已祭出，您花巨资营销的高流量来了没？我成功攻击了Tomcat服务器，大佬们的反应亮了 公众号：码大叔 资深程序员、架构师技术社区 微服务 | 大数据 | 架构设计 | 技术管理 个人微信：itmadashu
2020-06-04
优秀的个人博客,低调大师

从技术思维角度聊一聊，『程序员』摆地摊的正确姿势

云栖号资讯：【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 有人说程序员这个职业，三年升高工，七年做架构，十年送外卖。对此虽然我也曾非常认可，但现在我可以前瞻性(马后炮)地说四个字，杞人忧天!目光肤浅!正所谓天生我材必有用，用完再把外卖送，现在，新的风口——万亿【烟火经济】来了，除了送外卖我们又多了个新选择：摆地摊!一个人一辈子只有那么几次机会可能实现财务自由，机遇稍纵即逝，一定要牢牢把握住。所以，今天我们来严肃认真地聊一聊程序员摆地摊的正确姿势。 01 技术储备 程序员是谁? 一群志存高远立志要靠技术改变世界的人! 一群囊萤映雪时刻站在技术风口的人! 一群镂月裁云面试可以造火箭的人! 一群居安思危28岁就时刻焦虑未来的人! 正所谓打铁还需自身硬，在我们决定投身摆摊大业之前，一定要认清自己找准定位，了解自己在摆摊行业能够达到什么级别?根据程序员这些年来面试招聘的经验我可以给大家一点参考，我认为一个合格的P6级别地摊员应该具备改变全球宏观经济走向的能力，具有将各类地摊货抽丝剥茧再从0到1的能力。 P6级别地摊员面试题举例： 请说说摆地摊背后的经济学原理。 画一张从家到摆地摊地点的地图，0表示可以走，1表示不可以走，请编写一个程序，用合适的算法找到最短路线。 摆地摊可以有很多工具：一块布、地摊三轮车、私家车后备箱、五菱宏光、蓝翔挖掘机，请对比一些这些工具的优缺点?并讲讲你最熟悉的一个工具的运行流程。 摆地摊的过程中，亿级流量过来怎么办?高并发怎么办?高可用怎么做? 这几道题熟悉吗?如果你答不出来，建议你再回去多看看书，推荐几本： 《摆摊人员的自我修养》 《摆摊的二十三种设计模式》 《深入源零件，了解摆摊车的工作原理》 除此之外，还需要多读一读国外大佬的英文原版著作，特别是一些诺贝尔经济学奖大佬的，比如凯恩斯的《就业、利息和货币通论》、约瑟夫·熊彼特的《经济发展理论》、萨缪尔森的《经济学》、西蒙·库兹涅茨的《各国的经济增长》等。 “你先回去吧，正常我们会在两个星期左右给你答复。” “码大叔，恭喜你通过了我们的面试，你接下来的工作就是和我一起搬羊肉串” 原来所谓的合适，只是你能不能和我一起吹个很爽的牛，然后干件平凡的事。 我是摆地摊的，但是我就想和你聊一聊八千里路云和月! 02.找准方向 做好技术储备认清自己后，接下来就是找准方向，好的方向是成功的一半。很多人也想去摆地摊，但无奈不知道该做什么，导致自己始终迈不出摆摊的第一步。这件事对于程序员就比较简单，无非三个选择。 选择一：技术导向型创业 大多数程序员是有技术情怀的，通过自己的技术去改变或影响一批人，从而带来自己的商业价值。所以如果选择这个方向的摆摊，完全不需要考虑，看自己擅长什么，可以去制造摆摊车，可以去制造一些小商品，取决于自身能力。 选择二：技术入股型创业 做好你技术分内的事吧!用程序员的专业术语来说，就是单一职责，解耦合。至于什么方向交给你的合伙人，让专业的人做专业的事! 选择三：加入一家牛逼的摆摊公司 我们需要做的就是做好业务抽象和建模，设计一套通用的摆地摊架构，卖什么不重要，重要的是我们什么都能卖。具体卖什么由产品经理和运营大佬去商量。这个时候选择一个好的团队很重要，我们团队就很好，就有一个资深产品经理，可以和程序员打成一片。 “那边两个人在做什么” “穿格子的是程序员，还有一个是产品经理。产品经理说摆地摊一定要注重用户体验，简化用户的操作。举个栗子假如我们的地摊货是手机壳，你不能让用户挑来逃去这样体验太差，效率也很低。你得能根据用户的心情自动变换颜色、背景，说完两人就开打了，打了一年多没停手。” 你看，对于程序员，选择是如此简单! 困住我们手脚的，是顾虑! 早已成年的我们，需要的可能是那么一次年少轻狂、肆无忌惮! 03.微服务架构 首先，我们来看一张图： 看出什么问题没有? 对，太明显了，这还是传统的摆地摊方式，最初级的单体地摊架构!这样使得地摊服务过于臃肿，全部集中在一个人身上，不利于管理;容错性差，一旦出点小问题，就会导致整个服务宕机。比如用户要用支付宝付款，结果手机没电了，你得等着他呀，其他客户怎么办?而且这样也不利于扩展，摆摊事业做大了怎么支撑?还有一个最大的问题，就是它不符合当今地摊行业的潮流， 所以，最正确的姿势应该是：拆!将整个地摊的架构微服务化。你别管它合不合适，这都2200年了，顺应潮流、顺流而上，你才不会被潮流淹没，不会被这个时代所抛弃。不然你只能回去继续写你低端的代码，干不了地摊员。 如上图所示，微服务化后就成为上面这样的，有人管销售，有人管结账，有人管商品，有人管库存，有人管开神车。这样拆下来，它使整个地摊的分工更加明确，责任更加清晰，每个人专心负责为其他人提供最专业的服务。 独立的可扩展性，每个微服务都可以独立进行横向或纵向扩展;比如上面提到的收银服务慢，再来一个人呗; 独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务;比如五菱宏光要升级成蓝翔挖掘机，升级就是了。 易维护性，每个微服务的只专注于完成自己业务范畴的事情;你不用同时担心库存够不够，钱会不会算错等等，每个人专注自己的一部分。 故障和资源的隔离性，在系统中出现不好的资源操作行为时，例如销售忙到瘫痪导致内存泄露，后续的结账还可以继续进行。 等等 术业有专攻，专业的人做专业的事，你们我们像不像一个个微服务?当我们夸夸其谈其先进性的时候，以为自己走在技术前沿的时候，以为自己支撑了一整个服务集群的时候，我们可能已经忘了，这个事情我们已经做了很久很久，这个地方我们已经待了很久很久。我们以为自己是一个独立的服务可以独立地运作，却从来没有想过脱离了这个服务体系的时候，其实，一无是处! 单体应用，还是微服务? 我们需要什么? 这个世界需要我们什么? 04.放眼未来 作为具有程序员背景的地摊员，我们的目光不能局限于当下，要充分考虑未来地摊事业发展对当前架构的依赖及可能存在的风险，提前做好风险预案。比如： 万一有亿级客户流量来访问我们的地摊呢?我们该如何做好流量控制?熔断降级? 要不要再准备一队地摊员做好主备和负载均衡等? 我们的地摊货要不要分库分表呢? 要不要做读写分离，专门安排人员负责客户询价、地摊货咨询等? 要不要引入排队机制?要不要给他们发个令牌才能来我们的地摊呢? 等等 还有很关键的一点，地摊事业未来会不会遭遇某些人的封禁或者打压，比如： 万一有人说地摊是他们国家的物质文化遗产，是他们发明的呢? 万一有人觉得红火的地摊事业影响到了他们的安全，要将我们列入实体清单进行管制呢? 地摊，作为一个炙手可热的风口产业，一个充满无限可能的产业，让我们一起去摆摊吧。虽然我的想象力不足以想象地摊业的未来，但我的心里有火，眼里有光。即将投入地摊事业的程序员们，请接受我的祝福, 奔涌吧，地摊员 我们在同一条奔涌的河流。 它是一个地摊， 它是一个机会， 它是大千世界， 它是我们的内心。 梦想还是要有的，万一实现了呢? 梦想还是要有的，至少这样当我们想努力拼搏一把的时候，知道该往哪个方向! 写着写着我忽然想起来，这个摆地摊的架构好像还有优化空间，要不要再上个中台系统呢? 得好好考虑考虑一下! 【云栖号在线课堂】每天都有产品技术专家分享！课程地址：https://yqh.aliyun.com/live 立即加入社群，与专家面对面，及时了解课程最新动态！【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间：2020-06-05本文作者：剑圣本文来自：“51CTO”，了解相关信息可以关注“51CTO”
2020-06-04

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册