兼职可以吗...目前在职,离职也得要一个月呢

@louettagfh
@zhgg0
@vk42
@lyi4ng
@no1xsyzy
@Jooooooooo
是否内存在一开始就已经被分为了两部分 一部分是内核可访问的,一部分是用户可访问的,但是读出来的数据被放在了内核可访问的内存区域,所以要将他拷贝到用户可访问的内存区域

@louettagfh
@zhgg0
@vk42
@lyi4ng
@no1xsyzy
@Jooooooooo
谢谢大家的热心解答,不过感觉大家说的都太专业了,我是做 Java 开发的,确实对底层的系统层面的知识不是很了解,主要是我最近看了 fork,还有零拷贝这些知识,对有些概念还是很模糊,有个大概认识,比如 fork 就是将虚拟内存考了一份,然后写时复制,然后就是读文件在内核态和用户态进行切换的问题了(我在试图把这些内容串起来理解)
我再把我的想法描述清楚点,我认为内核态和用户态可以粗略的理解为内核进程(权限高,想干嘛就干嘛)和用户进程(权限低很多事干不了)吧?(我不知道对不对),然后是因为用户进程没办法和磁盘进行交互读写,所以需要调用内核进程来完成相应的功能,于是我们调用读文件的时候,其实系统是切换到了内核进程执行读文件的代码,然后将文件内容读到了内存里,看大家完大家的说法,感觉这个应该是读到了内核进程的专属一块内存里,用户进程依然没法访问,所以才又将内容拷贝了一份?现在内存里有了两份文件的内容?
但是我还是有点不明白,如果是按照进程来理解的话我们操作的都应该是虚拟地址才对,为啥内核不直接把读进来的内容在内存上的物理地址告诉用户进程(比如是哪几页),然后用户进程维护个虚拟地址就好了,为啥还要在物理内存上考一份,这个文件的内容在物理内存里到底是一份还是两份?
我觉得我现在的问题可能是不太明白啥是用户态和内核态

别沉 大神帮忙看看

@hantsy 是 jar 部署 不过是 springboot1.x 用的是 tomcat 连接池
@gz911122 不知道呀...没有思路 我现在只是发现问题 ,但是不知道怎么解决

还可以绑架老板她老婆哦

加油

会 知乎上多了会 你会以为大多数人都财富自由了

@foam 再说说水平扩容 你的意思应该是采用集群模式, 然后集群中的每个节点还有个镜像是吧...比如 3 台 mq 集群 然后再开三台镜像模式的节点 ,但是我看了 mq 的集群模式 他是只同步元数据 就队列,交换机什么的.. 队列的数据还是只有一台机器会保存,其他的机器如果收到该队列的请求只会转发到对应的机器,不知道 rmq 有没有把一个队列分开存的模式...

@killerv 需要异步还原库存

@foam
2.1 这里比较担心的是 假设我每分跑一次定时,查询之前所有超时的订单 比如我查到了 3w 条,然后逐条处理假如处理到 1.5w 条的时候就已经一分钟了 下个定时任务又开始跑了 怎么避免重复处理的问题
2.2 现在担心的就是消息积压的问题 35 分钟可能会堆很多消息
2.3 的问题在极端情况下和 2.1 一样 不过确实要优于前两种方案, 这种方式进入 mq 的消息应该是少数,并且定时任务执行起来应该会挺快的 把复杂的逻辑部分交给 mq 那边异步处理 并不在定时任务里处理逻辑,但是应该在定时任务中更新订单状态,不然受限于 mq 的处理速度,可能第二个定时任务开始时,会将已经入队但是还未处理的消息再入队一次

@niubee1 @ty89 这个在正向流程确实没毛病 但是我们需要有个异步去还原未支付的库存呀...我们在创建订单的时候就把库存扣了

@Kyle18Tang 我都起了定时任务 感觉就不用再放 mq 了吧 这样是不是有点多余了....
@kisshere 没 就瞬时 35 分钟 几十万订单应该正常吧 哪敢跟双十一比哦
@ty89 重点就是怎么定时去修改这个字段呀 他不会自己改过来
@realpg 就是 redis 的 zset 吗?
@KasonPasser 商城和支付是两个系统,这边创建订单成功了才会到支付系统,但是到了支付系统可能不支付,所以才这样做的
@nvkou 订单信息是入了库的..
@ConradG 这个还好 不是 zrange 一次取出来 他是取马上要过期的一条(zset score 当分数嘛) 然后处理 峰还是削了的

@weiqk 就那会儿高 要搞活动 秒杀

@cabing 好的...

@wangyanrui nb 哈哈哈哈

@tairan2006 现在是镜像模式 他的分布式叫集群更合适吧 每台机器存的消息是一样的 容量上线就是单机容量 他的分布式只是提高了吞吐量

@wangyanrui 现在我们就是不太知道 mq 到底能存多少 而且我也没搜到水平扩容的方案,他们推荐的都是出队速度要大于入队速度才好
@tanrenye 谢谢分享 我懂你意思了 但是定时任务可能会给数据库比较大的压力呀 而且这个方案可能改动比较大哦
@BBCCBB 能上云早上了 哈哈哈哈 不让上云...
@dongisking 对的 我现在比较倾向这个方案
@fewok 这个只要订单创建成功就会入队 还是有点吓人 这里可能是瓶颈 其他的流程我们也在改造...
@cabing 不是速度问题 速度到无所谓 本身就是一个异步流程 主要是容量问题 怕的是存不下 几十万我觉得是没啥 但是领导 你懂得... 几十万 消息 就算 10k 每条 几十万也才几百 m 把 而且应该远小于 10k 每条的
@kaneg 这个可能给数据库造成比较大的压力 而且可能重复处理 需要做一些处理才行

@Varobjs 不是待取消 我们是下单之前都会放一下 到了三十五分钟还没支付就给他取消并还原库存, 所以就是支付了的也会通知