精华内容
下载资源
问答
  • 关联了看不到聊天记录
    千次阅读
    2019-06-05 10:42:50

    目录

    写在最前

    MySQL 对于千万级别的大表要怎么优化?如果已经达到了亿级别呢?

    1、能不分就不分

    2、数据量太大,正常的运维影响正常的业务访问

    3、表设计不合理

    4、某些数据表出现无穷增长

    5、安全性和可用性的考虑

    6、业务耦合性考虑

    加点佐料:借一波典故(三国迷)

    用户聊天记录存储表概况:

    一、表优化

    1、原建表语句

    2、新建表语句

    3、优化项

    3.1 优化索引

    3.2 添加消息分区日期字段

    3.3 修改 channel_id 的默认值为 2

    二、按自然月分片测试

    写在最前

    1、建库建表

    2、建库建表脚本

    3、mycat 配置

    3.1 修改 schema.xml 文件

    3.2 修改 server.xml 文件

    3.3 修改 rule.xml 文件

    4、重启 mycat查看状态

    5、配置分片表t_im_msg全局自增主键(本地时间戳方式)

    5.1 修改配置文件 server.xml 配置

    5.2 修改 sequence_time_conf.properties 文件配置

    5.3 在 schema.xml 文件中配置

    5.4 重启 mycat

    5.5 插入数据测试(暂不支持主键为null)

    三、导出数据

    1、导出语句

    2、数据处理

    2.1 删除 msg_id

    2.2 按数据对应字段插入数据

    2.3 插入测试库添加msg_sharding_date值(并发更新脚本)

    3、测试库导出数据做进一步处理

    3.1 导出数据

    3.2 删除 msg_id

    3.3 插入的字段必须包含分片字段

    4、导入数据到测试 mycat

    4.1 取一小部分数据测试验证导入 mycat

    4.2 后台执行脚本 import_im_msg.sh 导入所有数据

    4.3 执行!

    4.4 同开发测试及调优

    5、部署线上环境,导入数据到线上 mycat

    5.1 取一小部分数据测试验证导入 mycat

    5.2 后台执行脚本 import_im_msg.sh 导入所有数据

    5.3 与线上数据同步,实现双写持续更新数据,待开发后续更新业务


    写在最前:

    MySQL 对于千万级别的大表要怎么优化?如果已经达到了亿级别呢?

    千万级别,对于 MySQL 实际上确实不是什么压力,innodb 的存储引擎,使用的是 B+ 数存储结构,千万级别的数量,基本上也就是三到四层的搜索,如果有合适的索引,性能基本上也不是问题。

    但经常出现的情况是,业务上面的增长,举个例子如用户聊天记录存储表,数据量还会继续增长,为了应对这方面的问题而必须要做扩展,此时可能首先需要考虑的就是分表策略。

    当然分表,可能还有其它几个原因,比如表变大了,千万级的数据库,为了减少运维成本,降低风险,就想到了通过分表来解决问题,这都是比较合适的。

    分表的话,还是要根据具体的业务逻辑等方面来做。

    从一般运维的角度来看,什么情况下需要考虑分库分表呢?

    1、能不分就不分

    MySQL 是关系数据库,数据库表之间的关系从一定的角度上映射了业务逻辑。任何分库分表的行为都会在某种程度上提升业务逻辑的复杂度,数据库除了承载数据的存储和访问外,协助业务更好的实现需求和逻辑也是其重要工作之一。分库分表会带来数据的合并,查询或者更新条件的分离,事务的分离等等多种后果,业务实现的复杂程度往往会翻倍或者指数级上升。所以,在分库分表之前,不要为分而分,可以去做其它力所能及的事情,例如升级硬件,升级,升级网络,升级数据库版本,读写分离,负载均衡等等。所有分库分表的前提是,这些你已经尽力了。

    2、数据量太大,正常的运维影响正常的业务访问

    这里说的运维,举个栗子:

    (1)对数据库的备份。如果单表或者单个实例太大,在做备份的时候需要大量的磁盘IO或者网络IO资源。例如1T的数据,网络传输占用50MB的时候,需要20000秒才能传输完毕,因此整个过程中的维护风险都是高于平时的。1T的数据的备份,也会占用大量的磁盘IO,如果是SSD还好,当然这里忽略某些厂商的产品在集中IO的时候会出一些BUG的问题。如果是普通的物理磁盘,则在不限流的情况下去执行xtrabackup,该实例基本不可用。

    (2)对数据表的修改。如果某个表过大,对此表做DDL的时候,MySQL会锁住全表,这个时间可能很长,在这段时间业务不能访问此表,影响甚大。在此操作过程中的所有时间,都可以看做是风险时间。把数据表切分,总量减小,有助于改善这种风险。

    (3)整个表热点,数据访问和更新频繁,经常有锁等待,又没有能力去修改源码,降低锁的粒度,那么只会把其中的数据物理拆开,用空间换时间,变相降低访问压力。

    3、表设计不合理

    4、某些数据表出现无穷增长

    很好举例子,就如下面具体的案例用户聊天记录存储表,还比如各种的评论,消息,日志记录。这个增长不是跟人口成比例的,而是不可控的,例如微博的feed的广播,我发一条消息,会扩散给很多很多人。虽然主体可能只存一份,但不排除一些索引或者路由有这种存储需求。这个时候,增加存储,提升机器配置已经苍白无力了,水平切分是最佳实践。拆分的标准很多,按用户的,按时间的,按用途的,等等。。。

    5、安全性和可用性的考虑

    这个很容易理解,鸡蛋不要放在一个篮子里,我不希望我的数据库出问题,但我希望在出问题的时候不要影响到100%的用户,这个影响的比例越少越好,那么,水平切分可以解决这个问题,这样整体的可用性也会提升。

    6、业务耦合性考虑

    这个跟上面有点类似,主要是站在业务的层面上考虑,比如飞猪火车票业务和天猫业务是完全无关的业务,虽然每个业务的数据量可能不太大,放在一个 MySQL 实例中完全没问题,但是很可能飞猪火车票业务的 DBA 或者开发人员水平很差,动不动给你出一些幺蛾子,直接把数据库搞挂。这个时候,天猫业务的人员虽然技术很优秀,工作也很努力,照样被老板敲脑瓜。解决的办法很简单:惹不起,躲得起,把业务拆分到不同的实例上。

    加点佐料:借一波典故(三国迷)

    《三国演义》第一回:“话说天下大势,分久必合,合久必分。”其实在实践中,有时候可能你原本要分,后来又发现分了还得合,分分合合,完全是现实的需求,随需求而变才是王道,而 DBA 的价值也能在此体现,或分或合的情况太多。

    用户聊天记录存储表概况:

    库大小:82G

    表大小:71G

    AUTO_INCREMENT:1788396067

    表行数:158313898

    一、表优化

    1、原建表语句

    mysql> show create table t_im_msg_1 \G;
    *************************** 1. row ***************************
           Table: t_im_msg_1
    Create Table: CREATE TABLE `t_im_msg_1` (
      `msg_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fromid` bigint(20) unsigned NOT NULL,
      `toid` bigint(20) unsigned NOT NULL DEFAULT '0',
      `chatfrom` bigint(20) unsigned NOT NULL,
      `chatto` bigint(20) unsigned NOT NULL DEFAULT '0',
      `group_id` int(11) DEFAULT '0' COMMENT '群组id',
      `shop_id` bigint(20) unsigned NOT NULL DEFAULT '0',
      `pub_id` int(11) DEFAULT '0' COMMENT '消息类型:0表示普通类型,1表示平台客服',
      `channel_id` tinyint(4) DEFAULT '1' COMMENT '区分平台:1表示美丽说,2表示higo',
      `msg` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
      `ctime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
      `ext` text COMMENT '扩展信息json_encode',
      `source` char(10) NOT NULL DEFAULT 'web' COMMENT '信息来源',
      `type` varchar(16) DEFAULT '' COMMENT '消息类型',
      `is_read` tinyint(4) DEFAULT '0',
      `source_ip` bigint(20) unsigned NOT NULL DEFAULT '0',
      `is_del` tinyint(4) DEFAULT '0' COMMENT '消息状态:1表示删除,0表示正常',
      PRIMARY KEY (`msg_id`),
      KEY `fromto` (`chatfrom`,`chatto`,`is_read`,`msg_id`),
      KEY `fromto2` (`fromid`,`toid`,`is_read`,`msg_id`),
      KEY `tofrom` (`chatto`,`chatfrom`,`is_read`,`msg_id`),
      KEY `tofrom2` (`toid`,`fromid`,`is_read`,`msg_id`),
      KEY `group` (`group_id`,`msg_id`),
      KEY `ctime` (`ctime`,`msg_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户聊天记录存储表';

    2、新建表语句

    mysql> show create table t_im_msg_wf \G;
    *************************** 1. row ***************************
           Table: t_im_msg_wf
    Create Table: CREATE TABLE `t_im_msg` (
      `msg_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fromid` bigint(20) unsigned NOT NULL,
      `toid` bigint(20) unsigned NOT NULL DEFAULT '0',
      `chatfrom` bigint(20) unsigned NOT NULL,
      `chatto` bigint(20) unsigned NOT NULL DEFAULT '0',
      `group_id` int(10) DEFAULT '0' COMMENT '群组id',
      `shop_id` bigint(20) unsigned NOT NULL DEFAULT '0',
      `pub_id` int(10) DEFAULT '0' COMMENT '消息类型:0表示普通类型,1表示平台客服',
      `channel_id` tinyint(4) DEFAULT '2' COMMENT '区分平台:1表示美丽说,2表示higo',
      `msg` text COMMENT '消息内容',
      `ctime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
      `msg_sharding_date` int(10) NOT NULL COMMENT '消息分区日期',
      `ext` text COMMENT '扩展信息json_encode',
      `source` varchar(10) NOT NULL DEFAULT 'web' COMMENT '信息来源',
      `type` varchar(16) DEFAULT '' COMMENT '消息类型',
      `is_read` tinyint(4) DEFAULT '0' COMMENT '消息状态:1表示已读,0表示未读',
      `source_ip` bigint(20) unsigned NOT NULL DEFAULT '0',
      `is_del` tinyint(4) DEFAULT '0' COMMENT '消息状态:1表示删除,0表示正常',
      PRIMARY KEY (`msg_id`),
      KEY `idx_chatfrom` (`chatfrom`),
      KEY `idx_chatto` (`chatto`),
      KEY `idx_fromid` (`fromid`),
      KEY `idx_toid` (`toid`),
      KEY `idx_group_id` (`group_id`),
      KEY `idx_ctime` (`ctime`),
      KEY `idx_msg_date` (`msg_sharding_date`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户聊天记录存储表';

    3、优化项

    3.1 优化索引

    1> 对于 innodb 存储引擎,复合索引本身属于非聚簇索引,索引本身包含主键,如果再加上主键就额外增加了索引长度,降低了更新性能,索引剔除复合索引中的 msg_id。

    2> 同时有两个概念叫做窄索引和宽索引,窄索引是指索引列为1-2列的索引,宽索引也就是索引列超过2列的索引;对于消息查询(跟开发确认查询条件)不区分is_read,因此剔除is_read将索引变为窄索引,设计索引的一个重要原则就是能用窄索引不用宽索引,因为窄索引往往比组合索引更有效;

    3> 删除重复索引tofrom和tofrom 2,虽然查询需求消息的发送者和接收者转换了,也只需要 where 条件调整一下顺序而已,无需额外添加索引,况且还是更新频繁的消息存储表。

    4> 注意事项:

    • (1) 对于复合索引,在查询使用时,最好将条件顺序按找索引的顺序,这样效率最高;

    • (2) 何时是用复合索引根据where条件建索引是极其重要的一个原则;

    • (3) 注意不要过多用索引,否则对表更新的效率有很大的影响,因为在操作表的时候要化大量时间花在创建索引中;

    • (4) 如果索引满足窄索引的情况下可以建立复合索引,这样可以节约空间和时间。

    5> 删除所有复合索引,针对消息查询对 chatfrom、chatto、fromid、toid 分别建立索引以优化索引空间。

    3.2 添加消息分区日期字段

    即分区键msg_sharding_date,设置为 int 类型,存储格式如 20190510,提高查询速率

    3.3 修改 channel_id 的默认值为 2,即默认平台为YYYY

    根据业务需求变化确认更新

    二、按自然月分片测试

    写在最前:

    月数据量:4915810(2018-12)

    年数据量:47873090(2018)

    1、建库建表

    CREATE DATABASE if not exists higo_im$1-132(暂时规划 2015-2025)
    CREATE TABLE `t_im_msg` (
      `msg_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fromid` bigint(20) unsigned NOT NULL,
      `toid` bigint(20) unsigned NOT NULL DEFAULT '0',
      `chatfrom` bigint(20) unsigned NOT NULL,
      `chatto` bigint(20) unsigned NOT NULL DEFAULT '0',
      `group_id` int(10) DEFAULT '0' COMMENT '群组id',
      `shop_id` bigint(20) unsigned NOT NULL DEFAULT '0',
      `pub_id` int(10) DEFAULT '0' COMMENT '消息类型:0表示普通类型,1表示平台客服',
      `channel_id` tinyint(4) DEFAULT '2' COMMENT '区分平台:1表示美丽说,2表示higo',
      `msg` text COMMENT '消息内容',
      `ctime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
      `msg_sharding_date` int(10) NOT NULL COMMENT '消息分区日期',
      `ext` text COMMENT '扩展信息json_encode',
      `source` varchar(10) NOT NULL DEFAULT 'web' COMMENT '信息来源',
      `type` varchar(16) DEFAULT '' COMMENT '消息类型',
      `is_read` tinyint(4) DEFAULT '0' COMMENT '消息状态:1表示已读,0表示未读',
      `source_ip` bigint(20) unsigned NOT NULL DEFAULT '0',
      `is_del` tinyint(4) DEFAULT '0' COMMENT '消息状态:1表示删除,0表示正常',
      PRIMARY KEY (`msg_id`),
      KEY `idx_chatfrom` (`chatfrom`),
      KEY `idx_chatto` (`chatto`),
      KEY `idx_fromid` (`fromid`),
      KEY `idx_toid` (`toid`),
      KEY `idx_group_id` (`group_id`),
      KEY `idx_ctime` (`ctime`),
      KEY `idx_msg_date` (`msg_sharding_date`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户聊天记录存储表';

    2、建库建表脚本

    #!/bin/bash
    user='root'
    passwd='LeHe3306@hiGo2025'
    host='127.0.0.1'
    port=2025
     
     
    function mysql_conn01(){
        mysql -u${user} -p${passwd} -h${host} -P${port}
    }
      
    int=1
    while(( $int<=132 ))
    do
        echo "${int}"
        db="higo_im${int}"
        echo "CREATE DATABASE if not exists ${db};" | mysql_conn01
        tb="/data/soft/wufei/higo_im/t_im_msg.sql"
        cat ${tb} | mysql -u${user} -p${passwd} -h${host} -P${port} -D${db}
        let "int++"
    done

    3、mycat 配置

    3.1 修改 schema.xml 文件

    <schema name="higo_im_test" checkSQLschema="false" >
            <table name="t_im_msg" primaryKey="msg_id" dataNode="higo_im$1-132" rule="sharding-by-month" />
    </schema>
     
     
    <dataNode name="higo_im$1-132" dataHost="localhost1" database="higo_im$1-132" />

    3.2 修改 server.xml 文件

    <user name="mycat_inf">
            <property name="password">MYCATinf#^hiGo3LAQ7</property>
            <property name="schemas">higo_im_test</property>
    </user>

    3.3 修改 rule.xml 文件

    <tableRule name="sharding-by-month">
            <rule>
                     <columns>msg_sharding_date</columns>
                    <algorithm>partbymonth</algorithm>
            </rule>
    </tableRule>
     
     
    <function name="partbymonth"
                    class="io.mycat.route.function.PartitionByMonth">
            <property name="dateFormat">yyyyMMdd</property>
            <property name="sBeginDate">20150101</property>
            <property name="sEndDate">20251231</property>
    </function>
      
    <!-- 
        columns:标识将要分片的表字段
        algorithm:分片函数
        dateFormat:分片日期格式
        sBeginDate:开始日期
        sEndDate:结束日期(必须要创建结束日期,循环计算数据具体在哪个分片上,虽然不能用 >= 或者 <= ,但是可以用 between...and 和 in,如果没有结束日期将无法查询时间段只能扫描所有表,后期可灵活调整)
    -->

    4、重启 mycat查看状态

    5、配置分片表t_im_msg全局自增主键(本地时间戳方式

    ID= 64 位二进制 (42(毫秒)+5(机器 ID)+5(业务编码)+12(重复累加) 

    即换算成十进制为18位数的long类型,每毫秒可以并发12位二进制的累加。

    5.1 修改配置文件 server.xml 配置

    <property name="sequnceHandlerType">2</property>
    <!-- 注:sequnceHandlerType 需要配置为2,表示使用本地时间戳生成sequence -->

    5.2 修改 sequence_time_conf.properties 文件配置

    # sequence depend on TIME
    WORKID=01 #0-31任意整数
    DATAACENTERID=01 #0-31任意整数
     
    # 多个 mycat 节点下,每个 mycat配置的 WORKID,DATAACENTERID 不同,组成唯一标识,总共支持 32*32=1024 种组合

    5.3 在 schema.xml 文件中配置

    增加表 t_im_msg,msg_id 为主键,在 higo_im$1-132 分片上,分片方式为 sharding-by-month

    <schema name="higo_im_test" checkSQLschema="false" >
          <table name="t_im_msg" primaryKey="msg_id" autoIncrement="true" dataNode="higo_im$1-132" rule="sharding-by-month" />
    </schema>

    5.4 重启 mycat

    5.5 插入数据测试(暂不支持主键为null)

    mysql> insert into t_im_msg(fromid,toid,chatfrom,chatto,group_id,shop_id,msg,ctime,msg_sharding_date,ext,source,type,source_ip) values(283099513902353978,0,1201367170,0,5166,0,'','2015-01-09 11:03:35','20150109','{"buy":"林阳刚买了 韩国 呼吸SUM37苏秘 呼吸惊喜水份套盒 6 只安瓶 清爽补水 收毛孔 !","buy_goodsid":"176204663976998975"}','pandora','higo_buy',169082962);

    三、导出数据

    1、导出语句

    坑 1:mysqldump 为了加快导入导出,默认把数据都缩减在一行里面。查看和修改不方便,为此,使用了--skip-extended-insert 选项来使导出的数据,是多行插入形式的(mycat不支持多行插入 insert into tab_a(c1,c2) values(v1,v2),(v11,v21)… )。

    坑 2:timestamp 数据类型导出时会有时区问题,导出机器默认为东八区时区(+08:00),而 mysqldump 导出时的TIME_ZONE=‘+00:00‘ ,这样导出的数据和表里看到的差了8小时。如果想在数据导出时不默认进行时区的转换,可以在导出语句中增加参数--skip-tz-utc,这样导出的timestamp数据和在表里看到的时候是一样的。

    mysqldump -uroot -pLeHe3306@hiGo2025 -h127.0.0.1 -P3215 --skip-extended-insert im t_im_msg_1 --skip-tz-utc > /tmp/t_im_msg_1.sql

    2、数据处理

    2.1 删除 msg_id

    # sed -ri 's/[0-9]+,//' [文件]

    2.2 按数据对应字段修改插入语句

    修改测试库 msg_sharding_date 字段默认值为 0

    修改 [INSERT INTO `t_im_msg_1` VALUES]为[INSERT INTO t_im_msg_1(fromid,toid,chatfrom,chatto,group_id,shop_id,msg,ctime,ext,source,type,source_ip) VALUES]

    # sed -i s/\`t_im_msg_1\`/t_im_msg_1\(fromid,toid,chatfrom,chatto,group_id,shop_id,pub_id,channel_id,msg,ctime,ext,source,type,is_read,source_ip,is_del\)/g[文件]

    2.3 插入测试库添加msg_sharding_date值(并发更新脚本)

    #!/bin/bash
    # 数据库配置参数
    user_inf='root'
    passwd_inf='LeHe3306@hiGo2025'
    host_inf='127.0.0.1'
    port_inf='2025'
    db_inf='im'
     
    # 数据库连接
    function mysql_inf01(){
            mysql -u${user_inf} -p${passwd_inf} -h${host_inf} -P${port_inf} -D${db_inf} -N
    }
     
    # import_im_msg_file='/data/soft/wufei/higo_im/t_im_msg_1.sql'
    # echo "show tables;" | mysql_inf01
    # echo "source ${import_im_msg_file}" | mysql_inf01
    echo "###############################################"
     
    # 最大并发数
    Thread_num=2000
    # 命名管道文件
    Tmp_fifo=/tmp/$$.fifo
     
    # 创建命名管道文件
    mkfifo ${Tmp_fifo}
    # 用文件句柄(大于最大并发数Thread_num)打开管道文件
    # 创建文件描述符,以可读(<)可写(>)的方式关联管道文件,这时候文件描述符2001就有了有名管道文件的所有特性
    exec 2001<> ${Tmp_fifo}
    # 关联后的文件描述符拥有管道文件的所有特性,所以这时候管道文件可以删除,我们留下文件描述符来用就可以了
    rm -rf ${Tmp_fifo}
     
    # 控制并发数
    for i in `seq ${Thread_num}`
    do
        # 向管道中放入最大并发数个行,供下面read读取
        echo >&2001
    done
     
    echo "select msg_id from t_im_msg_1 where msg_sharding_date=0 order by msg_id asc;" | mysql_inf01 | while read msg_id
    do
        # 通过文件句柄读取行,当行取尽时,停止下一步(并发)
        read -u 2001
        {
            echo "update t_im_msg_1 set msg_sharding_date=date_format(ctime,'%Y%m%d') where msg_id=${msg_id};" | mysql_inf01
            # if [ $? -eq 0 ];then
                echo "msg_id:${msg_id}" >> /data/soft/wufei/higo_im/import_im_msg_1.success
            # else
                # echo "update t_im_msg_1 set msg_sharding_date=date_format(ctime,'%Y%m%d') where msg_id=${msg_id};" >> /data/soft/wufei/higo_im/import_im_msg_1.error
            # fi
            # 一个并发执行后要想管道中在加入一个空行,供下次使用
            echo >&2001
        }&
    done
    wait
    # 关闭文件描述符的读
    exec 2001<&-
    # 关闭文件描述符的写
    exec 2001>&-
    echo "##########UPDATE SUCCESSFUL!!!##########" >> /data/soft/wufei/higo_im/import_im_msg_1.success

    3、测试库导出数据做进一步处理

    3.1 导出数据

    # head -n 和 tail -n 查看文件并删除注释行只留 INSERT 语句

    # mysqldump -uroot -pLeHe3306@hiGo2025 -h127.0.0.1 -P2025 --skip-extended-insert --set-gtid-purged=OFF -t im t_im_msg_1 --skip-tz-utc > /data/soft/wufei/higo_im_mycat/t_im_msg_1.sql

    3.2 删除 msg_id

    # sed -ri 's/[0-9]+,//'[文件]

    3.3 插入的字段必须包含分片字段

    修改 [INSERT INTO `t_im_msg_1` VALUES]为[INSERT INTO t_im_msg(fromid,toid,chatfrom,chatto,group_id,shop_id,msg,ctime,msg_sharding_date,ext,source,type,source_ip) VALUES]

    # sed -i s/\`t_im_msg_1\`/t_im_msg\(fromid,toid,chatfrom,chatto,group_id,shop_id,pub_id,channel_id,msg,ctime,msg_sharding_date,ext,source,type,is_read,source_ip,is_del\)/g[文件]

    4、导入数据到测试 mycat

    4.1 取一小部分数据测试验证导入 mycat

    4.2 后台执行脚本 import_im_msg.sh 导入所有数据(通过 mycat 导入)

    #!/bin/bash
    user_inf='wufei'
    passwd_inf='wufei'
    host_inf='127.0.0.1'
    port_inf='3025'
    db_inf='higo_im_test'
    tb_inf='t_im_msg'
     
    # MYCAT连接
    function mysql_inf01(){
            mysql -u${user_inf} -p${passwd_inf} -h${host_inf} -P${port_inf} -D${db_inf}
    }
     
    import_im_msg_file='/data/soft/wufei/higo_im_mycat/t_im_msg_1.sql'
     
    # echo "show tables;" | mysql_inf01
    echo "source ${import_im_msg_file}" | mysql_inf01

    4.3 执行!

    nohup /bin/bash /data/soft/wufei/higo_im_mycat/import_im_msg.sh > /data/soft/wufei/higo_im_mycat/error.log 2>&1 &

    4.4 同开发测试及调优

    5、部署线上环境,导入数据到线上 mycat

    5.1 取一小部分数据测试验证导入 mycat

    #!/bin/bash
    user_im='wufei'
    passwd_im='wufei'
    host_im='127.0.0.1'
    port_im='3215'
    db_im='higo_im'
    tb_im='t_im_msg'
     
    # MYCAT连接
    function mysql_im01(){
            mysql -u${user_im} -p${passwd_im} -h${host_im} -P${port_im} -D${db_im}
    }
     
    import_im_msg_file='/data/soft/wufei/t_im_msg_1.sql'
     
    # echo "show tables;" | mysql_im01
    echo "source ${import_im_msg_file}" | mysql_im01

    5.2 后台执行脚本 import_im_msg.sh 导入所有数据

    nohup /bin/bash /data/soft/wufei/import_im_msg.sh /data/soft/wufei/error.log 2>&1 &

    5.3 与线上数据同步,实现双写持续更新数据,待开发后续更新业务

     

     

     

    更多相关内容
  • 苹果手机微信聊天记录怎么恢复?如果我自己小心删掉了聊天记录,那该怎么办?为了解决这个问题,小编找到了三种可以有效恢复苹果手机微信聊天记录的方法!

    苹果手机微信聊天记录怎么恢复?在朋友圈里时不时就会看见有朋友发“怎么办,我真是蠢死了,不小心把聊天记录都删掉了,有圈友知道怎么恢复吗?”以前小编看见这种朋友圈,都叹了叹口气,心里想,如果是我自己不小心删掉了,怎么办?我大概会很抓狂吧,因为我自己的聊天记录是永远都不会删掉的,有些聊天记录甚至保留了几年了,为了以备不时之需,小编找到了这三种可以有效恢复苹果手机微信聊天记录的方法!

    在这里插入图片描述

    方法一:在电脑版iTunes中恢复微信聊天记录

    苹果手机微信聊天记录怎么恢复?iTunes是苹果的一款媒体播放器,同时也可以备份数据,能够很好地为用户解决数据丢失的问题,但是前提是先前就有使用iTunes进行数据备份,而且备份的电脑设备不能改变,否则进行到最后才发现功亏一篑。

    步骤一:下载电脑版iTunes到电脑上,Windows或者Mac都可以,完成安装后,打开电脑版iTunes就会看到以下画面。

    在这里插入图片描述

    步骤二:用数据线连接手机到电脑上,我们看到备份栏,点击“本电脑”,再看过去隔壁的手机备份和恢复,点击“立即备份”,整个过程就结束啦。

    备注:iTunes这个软件使用起来有点复杂的,正上方中间有备份的进度条,整个过程会有点久,要耐心等待,有些朋友会看到小编右下角框住了一行字,上面写着,“您从未将iPhone备份到这台电脑”,因为小编不怎么使用这款软件,所以这个方法对小编是没有用的。
    在这里插入图片描述

    方法二:在iCloud中恢复微信聊天记录

    苹果手机微信聊天记录怎么恢复?相信使用苹果手机的用户们对iCloud都是很熟悉的了,直接在手机上操作就可以备份了,而且有5G的免费备份空间,问题也来了,5G够用吗?答案是肯定不够的,我们现在的手机内存最少也在16G以上了,如果你备份的数据超过5G还想继续在iCloud上备份的话,就要付费了,但是少量的数据还是可以通过iCloud进行备份的。接下来看看如何在iCloud上恢复微信删除的聊天记录吧。

    步骤一:打开手机设置,点击我们的ID,下拉到有“iCloud”字样的部位,点击进去。

    在这里插入图片描述

    步骤二:继续下拉到有“iCloud云备份”字样的部位,一般习惯使用iCloud的朋友们这里已经是打开的状态,那么就可以正常到“通用”里面,点击“还原”,就可以了。

    备注:使用iCloud恢复数据,小编个人认为需要慎重使用,毕竟关联到一整个手机的数据,一不小心就会恢复出厂设置了,到那个时候真的就回不了头了,而且还是需要事前备份了才能进行恢复。

    在这里插入图片描述

    苹果手机微信聊天记录怎么恢复?好像前两种方法要不就是太复杂,要不就是很容易把数据一键清空,实在是不敢轻易尝试呀!没问题,小编这就把第三种方法给到大家!

    方法三:从iOS设备中恢复微信聊天记录

    寻找了多种方法吴无果,苹果手机微信聊天记录怎么恢复?数据蛙苹果恢复专家你可以大胆尝试使用,这款数据恢复软件不仅专业,操作起来也简单轻松,而且安全性能高。

    步骤一:下载数据蛙苹果恢复专家到电脑上,跟电脑版iTunes一样,都支持Windows或者Mac,安装完毕之后我们会看见以下画面,选择“从iOS设备中恢复”,使用数据线把手机连接到电脑上,并点击“开始扫描”。

    温馨小提示:最好使用原装数据线,在扫描过程中不要随意拔掉数据线,以防扫描失败的情况发生。

    在这里插入图片描述

    步骤二:扫描成功之后,我们会看到有微信通讯录、微信聊天记录、微信附件,这三种选择,数据蛙苹果恢复专家对于这三种模式都可以进行恢复,我们只需要点击需要恢复的信息,最后点击右下角的“恢复”即可。

    温馨小提示:大家日常中还是要有备份的好习惯哦,这样就可以避免不必要的麻烦了。

    在这里插入图片描述

    苹果手机微信聊天记录怎么恢复?看了小编介绍的三种方法,想必你们心中都有一个心仪的恢复方法了,小编选择的是使用数据蛙苹果恢复专家进行恢复删除的微信聊天记录,你们也是使用这款软件吧?

    展开全文
  • 背景 即时通讯(Instant Messaging),也就是我们常说的 IM,其实在很多业务场景上都会有或多或少的应用,有的会是核心,有的会是辅助。既然是聊天,那么必然就会产生聊天记录,而...

    背景

    即时通讯(Instant Messaging),也就是我们常说的 IM,其实在很多业务场景上都会有或多或少的应用,有的会是核心,有的会是辅助。

    既然是聊天,那么必然就会产生聊天记录,而且聊天记录随着人数的增加和时间的推移,很容易出现爆炸式的增长,这个对存储其实压力是很大的。

    举个大家都很熟悉的例子,一个群聊,几分钟不看,再打开就是 99+ 的未读消息。

    把即时通讯这个技术,放到医疗环境下,也是同样适用的。

    患者去线下医院看病,肯定离不开和医生的问答,这些问答,对系统来说,其实都是聊天记录。

    如果把这个场景放到线上进行,也就是正常的和我们在微信聊天那样了。

    说了那么多有的没的,也算是把大背景交代了一下,那么接下来就看看这个聊天记录存储的选型吧。

    技术选型

    既然要存储,那么肯定就会有很多选择,关系型数据库,非关系型数据库等。

    当然这个很大程度上是和具体业务场景挂钩的,离开了业务场景,基本就是在空谈。

    在医患关系里面的聊天记录,是一个十分十分核心的内容,并且必须要长期保存,不能丢,可查询。

    并且这些聊天记录是和某次问诊强关联的,所以单独拿出几条聊天记录出来,是没有意义的,因为他们没有关联,串联不起来。

    按照以往的经验看,一次问诊,医生和患者之间的聊天记录在 50 条之内的占据了大部分,超过50条的,占少数。

    这个和其他的 IM 情景可能不太一样。

    MySQL

    业务开始,大概率就是选用 MySQL 去存了这些数据了,单库单表,但是这种情况下很容易达到单表千万和上亿的级别。

    后面面临的基本就是分库分表的操作了。

    分库分表,基本就是根据问诊号去进行哈希,然后放到不同的库不同的表。

    这里会有一个不确定因素,分多少个库和分多少张表?

    分的多,囊中羞涩;分的少,再一次达到量级的时候又要重新分,大动干戈,这个时候最怕的就是动到了哈希的规则。

    所以选 MySQL 的话,到了中后期确实还是会有一点力不从心。线性扩展对这一块还是非常重要的。

    如果想改动小,避免分库分表,或许可以试试 TiDB,但是它要的配置,也不是中小企业所能接受的,80% 以上的概率会被 Pass 掉。

    https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements

    Cassandra

    Cassandra 是一个分布式、无中心、弹性可扩展的 NoSQL 数据库,基于 Amazon Dynamo 的分布式设计和 Google Bigtable 的数据模型。

    https://cassandra.apache.org/doc/latest/architecture/overview.html

    为什么考虑选型 Cassandra 呢?对上面说的医患场景,严格上是属于写多读少的,查询基本只会基于问诊号去查询,这个是相对比较明确的。

    Discord 在 2017 年的时候有一篇博客讲述了他们是怎么存储数十亿消息记录的 ,说的比较详细了。

    https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7

    其实他们选数据库的诉求,也是符合大部分涉及 IM 这一块的。

    老黄也是从这里受到了启发,认识了这个数据库。

    经常拿来比较的话,应该是 HBase,一个在国内火,一个在国外受欢迎。

    可以看看这个对比,了解一下两者的异同:https://www.scnsoft.com/blog/cassandra-vs-hbase

    如果选择要用 Cassandra, 那么数据模型的设计,一定是所有环节中最为重要的一步,如果这一步没有做好的话,那后面基本上会是灾难级别,基本不能愉快的玩耍。

    那么对医患关系里面的这个聊天模型其实比较简单。

    CREATE TABLE IF NOT EXISTS messages(
        inq_id text,
        send_time bigint,
        sender_id text,
        sender_role tinyint,
        msg_type tinyint,
        msg_body text,
        PRIMARY KEY (inq_id, send_time)
    ) WITH CLUSTERING ORDER BY (send_time ASC)
    

    对照正常的 IM 群聊, 这个问诊号 (inq_id) 就可以认为是一个群聊,一个频道。

    为什么没有消息Id这样的字段呢?多来源,非自研,无实际意义。

    下面再来看看如何在 C# 里面进行操作, 这里用的是 DataStax 提供的 CassandraCSharpDriver 客户端。

    写入:

    var cluster = Cassandra.Cluster.Builder()
                            .AddContactPoints("127.0.0.1")
                            .WithDefaultKeyspace("messaging")
                            .Build();
    
    var inqId = "xxxxxx";
    var sendTime = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
    var senderId = "xxxx";
    var senderRole = 1;
    var msgType = 1;
    var msgBody = "zzzz";
    
    string INSERT_SQL = @" INSERT INTO messages(inq_id, send_time, sender_id, sender_role, msg_type, msg_body)
    VALUES (?, ?, ?, ?, ?, ?) ";
    
    var session = cluster.Connect();
    
    var stmt = session.Prepare(INSERT_SQL).Bind(inqId, sendTime, senderId, senderRole, msgType, msgBody));
    
    session.Execute(stmt);
    

    读取:

    var cluster = Cassandra.Cluster.Builder()
                    .AddContactPoints("127.0.0.1")
                    .WithDefaultKeyspace("messaging")
                    .Build();
    
    var inqId = "xxxxxx";
    
    string GET_MSG_SQL = @" SELECT * FROM messages WHERE inq_id = ? ";
    
    var session = cluster.Connect();
    
    var stmt = session.Prepare(GET_MSG_SQL).Bind(inqId);
    
    var rowset = session.Execute(stmt);
    
    Console.WriteLine("患者\t\t\t\t\t医生");
    
    foreach (var row in rowset)
    {
        // 解析从 cassandra 中返回的行
        var msg_body = row.GetValue<string>("msg_body");
        var sender_role = row.GetValue<sbyte>("sender_role");
    
        if (sender_role == 0)
        {
            Console.WriteLine($"{msg_body}\t\t\t\t\t");
        }
        else
        {
            Console.WriteLine($"\t\t\t\t\t{msg_body}");
        }
    }
    

    写在最后

    存储的选择其实还是有点门道的,根据不同的应用场景,找出比较适合当前场景的几个方案,再选择一个成本没这么高的。

    Cassandra 对聊天记录这个场景的存储还是有一定优势的,可以应对高速的数据增长,而不用在业务代码层做过多的适配;部署相对简单,无特殊依赖,运维成本相对较低。

    展开全文
  • 腾讯员工用户聊天记录会被开除 在微信公开课Pro直播演讲中,微信创始人张小龙称经常收到用户质疑微信暴露聊天记录的投诉,张小龙表示:“我们确实不会你们的聊天记录,我们公司的人都是知道的,因为如果要会...

    点击上方 阿拉奇学Java,选择 设为星标

    每天0点,干货准时奉上!

    程序员新鲜事(ID:CoderNews)整理 内容参考自:时代财经、Techweb、封面新闻

    1月19日,一年一度的微信公开课Pro在广州举行。一向低调的腾讯公司高级执行副总裁、微信事业群总裁张小龙今年“凡尔赛”了一把。

    张小龙说,自己不怎么用QQ,但需要一个沟通的工具,想到很多人可能和自己有一样的需求,所以做了微信。

    截至2020年9月30日,微信的月活跃账户数达12.12亿。

    但他没想到会做成今天这样,他说:“我觉得自己特别幸运,是被上帝选中的那个人,因为靠自己是做不到现在这样的”。

    此外,张小龙还披露了几组有趣的最新数据:

    • 2020年,每天有10.9亿用户打开微信,3.3亿用户进行了视频通话;

    • 7.8亿用户进入朋友圈,1.2亿用户发表朋友圈,其中照片6.7亿张,短视频1亿条;

    • 3.6亿用户读公众号文章,4亿用户使用小程序;

    • 2亿人朋友圈设置仅三天可见,1.2亿的人设置了拍一拍的尾巴,每天有几千万人在拍

    • 还有很多,包括微信支付,企业微信,微信读书,搜索等,就不一一说了。如微信支付,它就像你以前的钱包一样,已经变成了生活常用品。而微信,也真的成为了“一个生活方式”。

    回顾十年,张小龙从产品的角度,将微信做过的事情归结为两个词,分别是连接和简单。现在的微信几乎和十年前一样简单,增加的功能都是用最简单的方法做到的

    他说,连接是很美的,世界也是万事万物连接起来的,微信最早提出连接人,后来连接服务、连接内容。做连接,会让我们知道,我们的重心不是做内容,而是做底层。

    至于简单,张小龙认为它能代替美观、合理、优雅,可能很多人不认同,但在他看来,简单是很美的,最简单的,也可能是最好的。现在微信,和10年前相比,可能多了很多功能,但这些功能都已经是最简化的。

    视频号一年之变

    除了对微信十年的一些总结,在不足两小时的演讲中,张小龙把超一半的时间,给了视频号,其他时间则分别谈了关于直播以及一些微信新功能的内容。

    2020年1月19日,视频号开始内测,如今已经迭代4个大版本,陆续支持了顶部分栏、转发朋友圈大屏显示、长视频、直播打赏、连麦等能力。

    最近5年,用户每天发送的视频消息数量上升33倍,朋友圈视频发表数上升10倍。张小龙判断,视频化表达应该是下一个十年的内容领域的一个主题

    在此次公开课上,张小龙澄清了一个外界传言很久的话题,他说,很多人说视频号是公司的战略重点,但并不是,公司的重点还是在微视。

    而视频号没有问公司要什么资源,一开始的定位是“视频化的微博”;视频号只做内容的承载和传递。

    他表示:“视频号不是一个任务,而是自己给自己的一个挑战”。

    下个版本或有直播入口

    在此次公开课上,张小龙谈到最近非常火热的直播,他认为,直播未来可能会成为一种个人的表达方式,直播的终极形态是每个人都是别人的眼睛,每个人都可以通过别人的眼睛看到想看的东西。

    张小龙透露,在微信的下个迭代版本中,底栏的发现页面增加了一个名为附近的直播和人的一级入口,点击后可以直接进入视频号的直播栏目。张小龙判断,在内容形态的演变中,直播已进入到更容易被大众接受的阶段,有巨大的机会;微信的下个版本或有直播的直接入口。

    张小龙预测,未来的直播将加载电商能力,或者嵌入小程序,也不排除直播与春节产生某种关联性的可能。“希望今年有一些人可以通过直播的方式来拜年。”

    剧透微信的5大新功能

    张小龙说,做产品就是要有一些异想天开的想法,虽然很多不能成功,但如果成功了就会很有意思。

    在此次公开课上,张小龙剧透了一些微信即将推出的新版本的一些新功能,比如新的表情开发、微信状态、微信里听歌、浮窗功能、输入法等。

    新版本微信的能力:关于表情的尝试;关于状态,会对视频动态进行升级,让对方正在做的事情被看见、被知道;关于听歌的尝试,听歌体验做了视觉化的展现。还有一些小改动,包括浮窗、快速找回看过的内容。

    微信将推出输入法,希望它是信息输入的第一个入口,会有一些想象不到的输入方法产生。

    张小龙说,其实微信不会看用户的输入内容,那些信息要经历很多地方,不只是微信。但也是从这个出发点,微信决定要自己做输入法,只要用户信得过微信的隐私保护,也会信得过微信输入法的隐私保护,很快,微信输入法就会进行灰度测试。

    腾讯员工看用户聊天记录会被开除

    在微信公开课Pro直播演讲中,微信创始人张小龙称经常收到用户质疑微信暴露聊天记录的投诉,张小龙表示:“我们确实不会看你们的聊天记录,我们公司的人都是知道的,因为如果要看会被开除的,我们这里不保存聊天记录。”

    但他表示,相关规定的要求下,会留存近三天聊天记录备查

    同时,他透露,为了更好地保护用户隐私,微信将在近期灰度测试输入法

    “那为什么(用户)在微信说了什么,会收到(相应)广告呢?”张小龙说,“从这个出发点,我们技术团队聊到,我们为什么不自己做一个输入法,我说好啊,我们有这个技术团队,这个团队是做机器翻译的,有很好的AI积累,他们也想验证自己的技术水准,在输入方法这里,我们前期做一些投入还是很好的。”

    张小龙微信之夜演讲全程完整视频:

    -- END --

    回复「进群」即可进入无广告技术交流群。同时送上250本电子书+学习视频作为见面 
    
    有你想看的精彩 
    
    
    阿里开源的 Arthas 在做 Java 应用诊断上真真太牛了!!
    换掉 Maven,我用它!!!
    我为什么放弃RESTful,全面拥抱GraphQL
    面试算法题:1 到 1000 之间有多少个 7?
    大佬终于把鸿蒙OS讲明白了,收藏了!
    开源!基于SpringBoot的车牌识别系统(附项目地址)
    几句话,离职了
    还在用分页?太Low !试试 MyBatis 流式查询,真心强大!
    目前5000+ 人已关注加入我们
    
           
          
    
    展开全文
  • 在之前部署完微软UC的时候,经常发现在Lync客户端中无论如何都查看不到Lync的聊天记录。 最后经过研究和打听才知道,原来Lync的聊天记录是跟Outlook做集成的。而此处Lync是否显示聊天记录是受Lync得Outlook ...
  • 继上个博客统计关键字次数的进阶,将关键词的次数制作成词云保存图片。之前说过的部分现在就说了,这里主要讲根据词频制作词云。1.安装wordcloud(这里要注意坑)这个安装的过程比jieba复杂,因为直接用pip ...
  • 首先你要得到微信的数据库,...获取的微信db后可以破解微信的db(是加密过的,破解方法也是百度可百的,这里讲),破解后通过工具连接。 微信是多库的,这里主要讲这个库 用工具打开后有很多的表,这里挑......
  • 这篇文章主要是分享一次web聊天功能开发的过程。在文章中首先会简单介绍什么是websocket和websocket的方法;然后再详细地介绍功能的实现,其中包括了数据库表的设计、前端页面的编写、接口的编写等。从前端后端...
  • 2022最新软件测试面试题,完还怕拿不到offer?

    千次阅读 多人点赞 2022-03-11 10:50:36
    bug能复现怎么办? 什么是HTTP协议,请求方法是什么?以及HTTP与HTTPS协议的区别? get与post请求的区别? 重载与重写的区别? App测试与web测试的区别? BS/CS架构的区别是什么? Android手机与iOS手机系统有什么...
  • 聊天框体实现:对话聊天

    千次阅读 2020-09-22 12:09:28
    一、前言 在上一章节我们实现了对话框体的 UI 部分...那么右侧被填充对话列表 ListView 需要与每一个对话用户关联,点击聊天用户的时候,是通过反复切换填充的过程。在没有实现这部分功能之前,你也可以先主动思考下...
  • 快给你的软件加IM聊天功能!

    千次阅读 2021-02-01 23:24:41
    一般来说,大部分即时消息系统为了便于查看历史消息或者用于暂存离线消息,都需要对消息进行服务端存储,因此,我们先来,这些互动过程产生的消息在服务端应该怎么存储或者暂存。 消息索引和消息内容 这里,我...
  • 用户表、群组表、用户群组关联表、好友表、对话表以及聊天记录表。用户在实际业务开发中可以自行拓展完善,目前库表结构只以核心功能为基础。 三、功能概述 在这套IM中,服务端采用DDD领域驱动设计模式进行搭建。将 ...
  • 用python对我和女票的聊天记录生成心形词云

    万次阅读 多人点赞 2018-01-20 14:00:12
    最近看到一些利用python制作词云的教程,突然想到用自己和女友的聊天记录做一个词云,看看平时我俩最常说的都是啥,然后用爱心的形状展示出来,以下是成品: 由于导出的记录只有最近两个星期的,再加上这两个星期...
  • 面试阿里被问JVM,逼逼赖赖,直接盘给面试官!!!概述JVM体系结构类加载机制类加载器类加载过程双亲委派机制全盘负责委托机制打破双亲委派机制自定义类加载器实现JVM运行时数据区程序计数器虚拟机栈本地方法...
  • 环信SDK 客服和IM聊天 踩坑记录

    千次阅读 2019-04-24 12:21:58
    1 、在使用前需要在Application初始化...环信并发接入权限也是个坑,必须要在登录前把权限都获取,否则会报打开SQLite数据库的错误,另外清单文件也需要添加几个,我贴几个容易被忽略的,关于权限的可以看看这个( ...
  • 聊天机器人比较1.OfficeBot (new)2.KUZENZendesk 聊天RICOH 聊天机器人服务AI.BIS 人工智能LINECLOVA 聊天机器人FAQ聊天机器人(NTTdocomo)sAI 聊天サポートチャットボット(本地用户)八鸟 (hachidori)OKBIZ....
  • 24 张图总结 TCP 基础知识,完我飘了。

    千次阅读 多人点赞 2021-06-21 10:56:13
    TCP 是一种面向连接的单播协议,在 TCP 中,并存在多播、广播的这种行为,因为 TCP 报文段中能明确发送方和接受方的 IP 地址。 在发送数据前,相互通信的双方(即发送方和接受方)需要建立一条连接,在发送数据后...
  • 用node.js实现一个简单的聊天

    千次阅读 2018-08-24 11:12:41
    刚刚开始学js,本文是基于node.js和websocket实现一个简单的在线聊天室系统(聊天群)。 本文适合纯小白阅读。 废话多说,我们正式开始。 在B/S架构中,我们要得到一个数据,要向服务器请求,然后服务器响应。...
  • 赛虎信息_天锐绿盾屏幕监控,不仅可以实时查看终端用户的操作行为并记录屏幕画面,还可以对重要应用程序开启特殊记录,保障企业的信息安全。
  • "黑产"识别算法前言黑产的特性通过业务特性识别通过关联关系识别(非监督学习)通过行为相似度识别(非监督学习)通过用户画像识别(分类、预测) 前言 我们讨论的黑产识别,实务上并非单纯算法的问题,在更多的情况下...
  • B站五面面经(附过程、答案)

    万次阅读 多人点赞 2021-07-06 08:45:48
    ​ (1)不要抱着有事我找你,没事我都认识你的态度去交流,平时需求对接正常沟通交流,人家有事找你,即使不是你负责的在耽误其他事的情况下帮忙解答一下,早上上班的见面了打个招呼,吃饭的时候聊聊天,或者经常...
  • 一文尽 2020 年谷歌 AI 重大突破

    千次阅读 2021-01-31 11:11:04
    2020 年,随着 COVID-19 肆虐全球,我们意识研发技术能够帮助全球数十亿人更好地交流、了解事态发展并找到新的工作方式。我为我们取得的成就感到自豪,也为即将出现的全新可能性感到振奋。 谷歌研究院的目标是...
  • 冥思苦想了一天,相出了个方案,能现实,但知道是不是最好的,希望对您有用!祝好! 要实现的功能是: 点击cc后: 再返回 消息提示不见了。 实现过程: 1,群里每个发言时要记下发言的时间戳 var message = e....
  • 备注:此功能是直接连接数据库存储,优化方案应该存储本地,但是页面刷新的时候,优先读取本地聊天记录,如果存储的是json格式,则需要自动解析,并取出对应的数据,存放页面上,当数据交少时,则可...
  • redis——相关问题汇总

    万次阅读 多人点赞 2019-10-16 10:09:19
    Redis 本质上是一个 Key-Value 类型的内存数据库, 整个数据库加载在内存当中进行操作, 定期通过异步操作把数据库数据 flush 硬盘上进行保存。 因为是纯内存操作, Redis 的性能非常出色, 每秒可以处理超过 10 ...
  • 本场 Chat,是基于 Python + Redis + Flask 来搭建一个简单易用的在线聊天室。完全从零开始,一步一步完成整个项目。 主要分享内容: ...对于 flask 太熟悉的同学可以先看看这个,Python 入门实战之鉴权系统...
  • Java实现在线聊天

    千次阅读 多人点赞 2022-08-26 17:47:51
    可以直接整合javat-io是基于java开发的一个开源的网络编程架构,大家都知道现在手机上或者电脑上都装了很多APP,这些APP都不是一个个在手机上或电脑上孤立的使用,而是能访问其他的地方数据或者与其他节点进行实时...
  • 本地文件自动同步GitHub

    千次阅读 2020-01-13 11:51:00
    前言只有光头才能变强。文本已收录至我的GitHub精选文章,欢迎Star:https://github.com/ZhongFuCheng3y/3y这篇文章主要讲讲如何自动将本地文件保存...
  • 用户可以通过客户端连接服务器端并进行网上聊天聊天时可以启动多个客户端。服务器端启动后,接收客户端发来的用户名和密码验证信息。验证通过则以当前的聊天客户列表信息进行响应;此后接收客户端发来的聊天信息...
  • 该篇文章从关系型数据库和非关系型数据库来讲述,牵扯设计、索引、隔离级别以及redis的应用场景、持久化、等进行详细描述,希望对您有用! 1、你是怎么设计数据库的? 设计数据库首先要遵循三大范式要求:原子性、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,947
精华内容 6,378
热门标签
关键字:

关联了看不到聊天记录