220的机械锁能改成ec3的电动锁吗!

北汽EC3拥有新都市Cross动感外观:搭配蓝、白、橙、红,4种外观颜色,个性时尚;M字前脸两侧各配有5颗竖排分布LED单元,提升科技感的同时有效保障日间行车安全;前格栅采用纯电动专属封闭式设计,饰条犀利动感,彰显新能源身份。

双液晶大屏潮流科技与简约风格融合内饰;中控区内饰型面曲率饱满,间隙均匀,搭配与车身同色多彩内饰饰板,活力时尚;7寸全液晶主仪表、8寸悬浮液晶中控屏(顶配),主副仪表盘分体设计,为驾乘者带来更清晰、更安全、更愉悦的出行体验。

EC3精致细节打造全新质感体验,中控仪表板采用领先同级的注塑双缝线工艺;标配软质扁平化三幅运动方向盘和软质包裹四门扶手,触感轻柔,观感升级,匠心铸造高级质感。

搭载N-booster智能电控刹车系统,可实现99.99%制动能量回收,有效提高续航、降低能耗;高效智能助力反应时间仅为传统助力的1/4,紧急制动情况下可缩短制动距离5m以上,刹车制动更灵敏、出行更安全。

采用高效水冷电机,冷却性能更好、运行效率更高、加速性更优,最高时速可达120km/h,畅行全国高速;0-50km/h加速时间小于5.5s,起步快,加速猛,推背感强,驾驶更添乐趣。

高密度宁德时代三元锂电池

标配高密度三元锂电池,并搭载业内高水准的宁德时代电芯,经30余项国际测试认证,全方位保障电池安全;专业电池管理系统及超低温预热充电技术,零下30度亦可正常启动及充电。

前后轴荷1:1运动底盘

配备专业级正向开发纯电动运动底盘,实现前后轴荷1:1,四轮受力更均匀,使汽车在加速、减速、转弯时,能够实现更平稳安全的操控;超过200万公里超长试验里程验证,品质更可靠、驾驶更安全。

搭载科大讯飞3.0智能语音交互操控系统,电话、音乐、天气、新闻、导航等丰富信息实时获取,精微语音识别,随时打断不卡顿,便捷语音交互解放双手。

标配7寸液晶高清数字仪表;轻松设置菜单,行车信息一目了然;两套UI界面随心切换,畅享出行新体验。

配备悬浮式8寸液晶中控大屏,除数字化车载信息显示外,更集成丰富互联功能,充分满足驾驶者出行娱乐和智能交互需求。

内置精准高效的高德导航,地图数据随时在线更新;路况信息实时显示,自动调整路线规避拥堵,轻松实现出行无忧。

云钥匙手机遥控App,随时查询充电剩余时间、续驶里程等车辆状态,用车更省心;冬寒夏热,可手机远程开启空调,出行更舒心。

根据各地补贴政策确定实际价格
等速法纯电续驶里程(km)
电机最大扭矩(N.m)
EPS电动助力转向系统
ISOFIX固定装置2个(儿童安全座椅接口)
扁平式皮质多功能运动方向盘 ●(音量、收音机调频) ●(音量、收音机调频)
副驾驶座遮阳板带化妆镜
百度CarLife手机智能互联
手机APP(远程信息查询)
手机APP(远程控制)
远程OTA刷新整车程序
标准USB接口带充电功能
● 表示标配 ○ 表示选装 - 无此配置


第一反应应该是死锁导致,先用show full processlist去找到正在运行的线程,没有抓取到对一个堵住的SQL,可能是达到死锁的超时时间自动对小的事务做了回滚。使用show engine innodb status\G;查看innodb中锁的信息,发现如下线索

确实有死锁,不过时间不对,从innodb日志看锁是在14:16的时候发生的,业务开发的同学反馈在16点的时候也有发生过update超时的情况。如果16点有发生过那么show engine innodb status\G; 看到的最近的一次死锁就不应该还是14:16分。因此初步判断业务开发同学反馈的update超时不应该是死锁,而是update在等待某个锁的时候执行超时了。既然是update在等待锁,那么就肯定有某个线程在持有锁,而且很长时间不释放。下面弄个抓取脚本就来个“现场”体验吧。
如果要取消这种方式,直接drop掉这个表即可。
写了个简单的抓取脚本,如果出现update超过8秒的时候就记录,就抓取show engine innodb status\G和show full processlist的信息。根据以往的经验有了这两个如果是死锁或者锁等待的情况,基本都能定位到对应的问题。 过了20分钟左右又出现超时了,此时看peocesslist的信息update都处于updating状态。

很奇怪,这种根据唯一索引做update的不可能要update那么久,难道是对应的update语句在事务中没有提交?电话业务的开发同事进行确认,业务开发的同学答复那些SQL都是自动提交的,没有放在显式的事务中。好奇怪,那么是什么导致SQL执行那么长的时间呢?初步判断这个update最大的可能是在等待获取锁。那么是什么语句在持有锁呢?如何才能找到真正持有锁的线程呢?记得之前阅读《高性能MYSQL》里有提到mysqladmin开启debug模式能查看到具体哪个线程在持有锁。
于是改进脚本,达到触发条件的时候开启debug,再继续等待,晚上9点半的时候终于又重现了,这次看看战果如何?

下面是debug模式找到的线程锁的情况:

诡异,这次debug显示是update的语句在持有锁,这个怎么解释都解释不通,怀疑这个debug有bug。
继续尝试,记得之前看MYSQL 5.5的文档的时候有提到说信息库中能记录关于线程持有锁、锁等待、以及事务锁等信息,于是查看官方文档,发现了有三个很有用的表,分别介绍一下:
这个表包含了每个事务在innodb内部的当前状态,包括当事务开始的时候或者事务在执行中是否在等待锁。
顾名思义,这个表显示那个事务在等待锁。
这个表记录了innodb的所有锁的情况,这里可以看到锁的信息、SQL线程ID以及锁定的数据等东东。
有了这些法宝再去更改抓取程序,当出现问题的时候抓取这三个表的状态。上午10点的多的时候又重现了,这次清晰了,先截图来分析一下:

有了这些信息足以了,综合上面3个表的信息可以知道,那个update语句是在等待锁,那个线程ID为的线程才是真正持有锁的语句。通过抓取的线程过滤一下看看:

从这里可以断定是某个事物中执行了查询表的操作后没有提交事务导致,将10.205.138.165提供给开发的同学检查后反馈确实有一个地方存在问题,截图如下:

key冲突了,导致insert失败,但是对GDXR3OHD70840D的锁还没有释放,因此在对这个project_no更新的时候就一直在等待。

找到问题就好解决了,如果insert失败就执行rollback的操作就OK了。自此世界安静了。
这里为什么是共享锁的,应该是插入的时候根据唯一索引,还要查询一下数据是否存在,因此加了共享锁。
通过上面的分析,模拟出分析的过程应该就能重现该问题,为了验证推论的结果是否正确,因此手工来重现一把。先创建一个表,并插入几条记录:


开启两个终端然后分别模拟线上出现的场景:
A终端模拟线上insert失败的操作


B终端模拟update的操作:


和线上出现的问题一样,当A终端进行commit或者rollback或者连接中断后B终端的update才能获取锁。和现场环境一样。

那三个lock的表只有5.5版本或者innodb plugin的版本才有。如果是5.1的没有安装innodb plugin的mysql该如何去找到持有锁的线程呢?等有时间了再来好好研究一下!

我要回帖

更多关于 防盗门快锁可以改成手动锁吗 的文章

 

随机推荐