1.�߲����ܹ�Դ��ȥ����
2.PolarDB-X 源码解读(七):私有协议连接的高并构源一生(CN篇)
3.10个不容错过的VSCode插件(上)
4.openGauss数据库源码解析系列文章——事务机制源码解析(一)
5.å½å
ä½ä»£ç å¹³å°åªå®¶å¼º
6.分布式锁技术探究 - Redisson & curator 源码解读
�߲����ܹ�Դ��ȥ����
大致上可以注意以下这几点,你可以作为参考:
1、发架设计的码去精美:每个人都喜欢看美丽的事物,而且在当今的找高移动互联网时代,人们都比较喜欢颜值高的架构东西。所以企业在搭建多用户商城系统源码的源码问卷调查网站源码时候,也需要通过精美的去找模板设计来提升企业网站的颜值。
2、高并构源营销方式:商城是发架一个系统,源码好不好也会影响这个系统的码去构建,而营销方式恰恰是找高这里面的一块,先不说营销系统本身,架构单纯这个体系上源码就直接影响营销方式不同。源码
3、去找质量过硬:多用户商城系统是高并构源一个网络商圈,源码优秀代表着质量过硬,无论是开发方面,还是功能,安全,稳定等等要求,都要达到优秀的水平!
4、用户满意度高:一个源码好不好,更多的市场价值,和用户评价,用户的满意度可以说是源码最为直观的一个体现!用户满意度越高,源码也就越好!
5、多用户商城系统源码的安全要求:源码直接影响整个商城,也是因此一个多用户商城源码如果连安全都满足不了,那么这源码要来何用?也是因此优秀的源码一定满足自身安全要求!多用户商城系统的交易过程具有信息的保密性、完整性和不可否认性等安全需求。
6、售后服务好:我们看源码只看产品吗?对于开发商更多需要注重售后服务这一块,可以说这是非常关键的,这就好比我在网上购物,某些时候还会联系商城售后,期间产生的情绪会直接决定商品的好与坏!也是因此售后很关键!
分析的以上几点,希望对你有所用帮助!
PolarDB-X 源码解读(七):私有协议连接的一生(CN篇)
通过前文的介绍,大家基本了解了一条SQL在polardbx-sql中的解析和执行流程。由于polardbx-sql是无状态的计算节点,真正数据需要从存储节点传输到计算节点,这部分工作由私有协议完成。本文将详细介绍从发送请求到存储节点,接收返回数据的完整流程,重点在于私有协议连接的生命周期和关键代码解析。
概述
为了提高数据节点本地计算能力,同时减少网络数据传输量,快卖出指标源码计算节点会尽可能下推计算内容。一个逻辑表可能需要多个物理分片,因此计算节点与存储节点的请求会话数量会随着分片数增加而增加。传统MySQL协议+连接池架构已不能满足PolarDB-X的需求,因此私有协议在这一需求场景下应运而生。
如图所示,私有协议采用连接与会话分离的RPC协议设计理念,支持多个会话在同一个TCP通道中并行运行,具备流控机制、全双工响应式工作模式和高吞吐、可扩展等特性。
更多关于私有协议解决上述问题的设计详情,可以参考《PolarDB-X私有协议设计》一文。本文主要从代码层面详细描述私有协议的工作流程。
我们将从计算节点和存储节点两个角度完整解析私有协议连接的生命周期。篇幅限制,本文仅关注计算节点上私有协议的处理,存储节点部分将在后续文章中详细说明。
计算节点
计算节点作为私有协议的客户端,负责发送下推请求,并接收返回的数据。
网络层框架
PolarDB-X私有协议网络层采用定制化Reactor框架实现,基于Java的NIO,改进自polardbx-sql中的Reactor框架。网络层初始化时,设置CPU核心数的2倍(上限为)作为NIOProcessor,每个Reactor使用独立的堆外内存池作为收发包缓冲,总缓冲内存大小限制为堆内存大小的%。
NIO接收的包直接调用注册的处理函数,发送数据仅写入send buf,网络写入由单独线程完成。线程优先写入TCP send buf,当无法写入时,注册OP_WRITE事件等待可写后再写入剩余内容。
数据包的编码和解码在NIOClient中实现。为实现最佳性能,解包流程直接在堆外内存上进行,使用protobuf对流直接解析,将结果放入堆内。堆外内存被切分为KB chunk,每个Reactor独占一个chunk,连续解析和复用,最大化接收、解析效率。对于特大包,额外构造堆内大buffer接收和解析,回退标志在定时任务中重置,连续s无超大包时释放堆内内存,恢复高性能堆外KB buffer接收。
请求发送集成在NIOClient中,writer优先尝试写入发送缓冲队列尾部的buffer,不足时新申请buffer填充并追加到队尾。同花顺超级单源码buffer来自预分配的堆外缓冲池,超过chunk大小时分配堆内buf进行序列化。
同时,NIOClient负责TCP连接的建立和断开资源释放,作为独立的底层网络资源管理实现。
连接及会话
网络层之后,我们聚焦连接与会话分离的具体实现。通过剥离连接及收发包的具体实现,连接和会话的管理变得更加清晰简洁。
首先,一个TCP连接的逻辑抽象结构在XClient中实现,为避免误解,取名为client与JDBC中的Connection区别。该类管理TCP连接和并行运行的会话,负责TCP完整生命周期的管理、认证鉴权,并维护公共信息。其中,workingSessionMap记录了连接上并行运行的所有会话映射关系,可快速通过会话ID找到对应的会话抽象结构XSession。
XSession提供了所有会话相关的请求函数和信息存储,包括执行计划请求、SQL查询请求、SQL更新请求、TSO请求、会话变量处理、数据包处理及异步唤醒等。
连接池及全局单例管理器
为了提高性能,TCP连接和会话的复用必不可少。由于连接和会话的解绑,连接池不仅缓存了到计算节点的TCP连接,也缓存了到计算节点的会话。
XClientPool管理到一个存储节点的连接池,通过IP,端口,用户名三元组唯一确定目标存储节点,同时存储该节点的全部TCP连接(XClient)和建立的会话(XSession)。
XClientPool实现存储节点会话获取,对应JDBC接口中的getConnection,同时实现连接和会话生命周期管理、连接探活、会话预分配等功能。实现单个存储节点连接池后,XConnectionManager维护目标存储节点三元组到实例连接池的映射,管理定时任务线程池,实现定时探活、会话&连接最长生命控制以及连接池预热等功能。
JDBC兼容层
新的SQL协议层对上层使用者要求较高,为了提高开发效率,私有协议提供兼容JDBC的使用方法,实现从JDBC平滑切换至私有协议,并支持协议热切换。直播类网页源码
JDBC兼容层代码目录在compatible目录下,Connection继承在XConnection文件中。提供包括DataSource、Connection、Statement、PreparedStatement、ResultSet、ResultSetMetaData在内的大部分常用接口函数实现,不支持的函数会明确抛出异常避免误用。
整体关系
至此,私有协议计算节点端的大部分结构已说明完成。给出一个整体的关系图。
私有协议连接的一生(CN视角)
了解了私有协议各层实现后,我们以发到存储节点的请求为例,完整梳理执行流程。绕开计算节点复杂流程,直接运行代码示例(注:需将com.alibaba.polardbx.rpc.XConfig#GALAXY_X_PROTOCOL设置为true)。
直接运行playground看到预期的select 1的结果。接下来,我们深入跟踪说明。
数据源初始化
要使用私有协议,需要初始化对应存储节点的XDataSource。构造过程中,XDataSource会到XConnectionManager注册新的实例连接池,已存在的连接池引用计数加一。
获取Connection
当需要执行查询时,首先获取会话。无论是显式开启事务还是使用auto commit事务,会话都是执行请求的最小上下文。通过XDataSource的getConnection方法获取到对应存储节点的会话。XDataSource根据存储的IP,端口,用户名三元组查找到XConnectionManager中的连接池,在最高并发检查后,会话获取逻辑在XClientPool实现。首先尝试在空闲会话池中拿会话,通过重置检查和初始化后返回给调用者。大部分场景下,ConcurrentLinkedQueue提供较好的并发性能。
在代码场景下,数据源刚新建,后台定时任务未运行,流程进入连接创建流程。会有一把大锁锁住连接池,在TCP连接未达上限且没有超时的情况下,快速新建一个XClient占坑。若超限,则进入busy waiting循环。真正的TCP connect(waitChannel)在锁外被调用,首先client以阻塞模式带超时方式connect,然后切换为非阻塞模式,round robin策略注册到NIOProcesser上,陌撩app源码返回时,TCP连接已建立。
为了兼顾安全和性能,连接鉴权在TCP建连后只用做一次,会话创建不需要鉴权。鉴权在initClient中完成,发送SESS_AUTHENTICATE_START_VALUE包,后续校验由回调完成。认证采用标准的MySQL认证流程,server端返回challenge值,库名、用户名和加盐hash后的密码返回给MySQL即可完成认证。
至此,到存储节点的TCP连接已建立,创建会话是一个异步流程。在创建新XClient时,XConnection已new好,通过下断点跟进去可看到newXSession流程,分配session id,设置状态为init,将XSession绑定到XConnection上。
最后,XConnection经过初始化(重置auto commit状态)、重置默认DB、默认字符集(lazy操作)和统计信息记录,返回给用户使用。
发送查询请求
拿到初始化好的兼容JDBC的Connection,为了简化流程,直接调用XConnection中的execQuery。XConnection的execQuery包装了XSession的execQuery,执行前执行了设置流式模式。
首先记录调用信息进行统计,进入关键的initForRequest流程。XSession初始化流程lazy,仅分配session id,设置状态为Init,真正创建session时发送SESS_NEW给server,绑定新session和session id。如果session已复用,则状态为Ready。
执行字符集更改的lazy操作,session可能在其他请求中切换字符集,根据目标字符集和当前字符集对比,决定是否发送额外的字符集更改请求。
经过一系列变量设置、lazy DB设置和protobuf包构造,请求发送到存储节点执行。发送后,同步生成XResult负责结果解析,同时XResult按照请求顺序依次拉链表,确保结果与请求一一对应。
请求流水线结构如下图所示,处理完成前序请求后,才能解析后续结果。
接收结果集
请求已发送到存储节点执行,拿到XResult,通过XResult收集查询结果集。XResult与发送请求一一对应,存储节点处理也是在会话上排队进行,不会影响流水线上其他请求的返回,保证流水线正常工作。
首先,查看结果集处理的状态机,主要状态包括获取元数据、获取数据行、获取额外信息等,顺序固定,根据请求类型,部分环节可能被省略。报错处理贯穿整个状态机,任何报错信息都会导致状态机进入错误处理环节。
对于非流式数据读取,请求结束时主动调用finishBlockMode将所有数据读出并缓存到rows中。对于流式执行的情况,结果集状态机消费数据包队列由XResult的next函数推动,内部函数internalFetchOneObject递归调用前序XResult,消费前序请求结果,从数据包队列中消费并推动状态机流转。
对于查询,首先收到RESULTSET_COLUMN_META_DATA包,表示返回数据列定义,一个包表示一列。元数据包后,收到包含数据行的RESULTSET_ROW包,一个包对应一行。数据行传输完成后,server端发送RESULTSET_FETCH_DONE标示数据发送完成。请求结束前,NOTICE包用于告知客户端rows affected等信息。最后,SQL_STMT_EXECUTE_OK包标示请求结束。
至此,完整请求处理完成,控制台应显示查询结果。
总结
本文详细描述了私有协议连接流程中的关键点和关键数据结构,相信通过本文描述,大家掌握了私有协议连接流程的基本点,在调试和修改使用中能够更加得心应手。虽然本文篇幅较长,但实际使用中涉及更多高级特性的使用,如多请求流水线、流控、执行计划传输、chunk结果集传输等。通过本文,我们对私有协议连接流程有了深入理解,为在实际场景中应用提供坚实基础。
个不容错过的VSCode插件(上)
本文介绍了个强大的Visual Studio Code扩展程序,旨在提升Web开发者的体验。每个插件都附有示例用法和安装链接,让开发者轻松上手。
首先,我们来看Prettier插件,它的安装链接是:marketplace.visualstudio.com...。Prettier是一个高效自动格式化代码的工具,它通过使用争议性和可定制的规则,帮助开发者保持代码风格一致,减少团队内部因代码风格不一致引发的讨论和争议,提高团队协作效率。使用Prettier的快捷键,可以轻松格式化代码,或在保存文件时自动格式化。
JavaScript Booster插件的安装链接是:marketplace.visualstudio.com...。它为JavaScript开发者提供了代码重构功能,能够优化代码结构和性能,提高代码的可读性和可维护性。JavaScript Booster支持许多快捷键和命令,简化代码重构过程,无论是进行大型项目重构还是优化小规模代码段,都十分便利。
ESLint插件的安装链接是:marketplace.visualstudio.com...。它是一款用于查找和修复JavaScript代码问题的工具,能够处理代码质量和编码风格问题,帮助开发者发现潜在错误,提高代码的可读性、可维护性和可靠性。Visual Studio Code的ESLint扩展程序与编辑器集成,方便在编辑器中发现和修复代码问题。
GitLens插件的安装链接是:marketplace.visualstudio.com...。它是一款强大的Git源代码控制工具,帮助开发者更好地管理和协作代码。GitLens提供文件历史记录、提交、分支和远程等关键数据视图,并支持多种Git工作流程,使版本管理和团队协作更加便捷和流畅。
Live Server插件的安装链接是:marketplace.visualstudio.com...。它允许开发者在本地启动服务器,实时预览网页更改,无需手动刷新页面。Live Server支持自定义端口、HTTPS支持、自动打开浏览器和多浏览器同步预览等功能,提升网页开发效率。
对于希望深入学习网络编程的开发者,推荐《Netty源码全解与架构思维》一书,它详细介绍了Netty的架构设计和思想,帮助开发者理解和应用Netty进行高效网络编程。
此外,还有更多与Java相关的资源和技巧分享,例如处理高并发的方法、FPGA与GPU的对比、提升Java程序性能的技巧等,欢迎通过《Java学研大本营》微信公众号加入读者群,获取更多精彩内容。
openGauss数据库源码解析系列文章——事务机制源码解析(一)
事务是数据库操作的核心单位,必须满足原子性、一致性、隔离性、持久性(ACID)四大属性,确保数据操作的可靠性与一致性。以下是openGauss数据库中事务机制的详细解析:
### 事务整体架构与代码概览
在openGauss中,事务的实现与存储引擎紧密关联,主要集中在源代码的`gausskernel/storage/access/transam`与`gausskernel/storage/lmgr`目录下。事务系统包含关键组件:
1. **事务管理器**:事务系统的中枢,基于有限循环状态机,接收外部命令并根据当前事务状态决定下一步执行。
2. **日志管理器**:记录事务执行状态及数据变化过程,包括事务提交日志(CLOG)、事务提交序列日志(CSNLOG)与事务日志(XLOG)。
3. **线程管理机制**:通过内存区域记录所有线程的事务信息,支持跨线程事务状态查询。
4. **MVCC机制**:采用多版本并发控制(MVCC)实现读写隔离,结合事务提交的CSN序列号,确保数据读取的正确性。
5. **锁管理器**:实现写并发控制,通过锁机制保证事务执行的隔离性。
### 事务并发控制
事务并发控制机制保障并发执行下的数据库ACID属性,主要由以下部分构成:
- **事务状态机**:分上层与底层两个层次,上层状态机通过分层设计,支持灵活处理客户端事务执行语句(BEGIN/START TRANSACTION/COMMIT/ROLLBACK/END),底层状态机记录事务具体状态,包括事务的开启、执行、结束等状态变化。
#### 事务状态机分解
- **事务块状态**:支持多条查询语句的事务块,包含默认、已开始、事务开始、运行中、结束状态。
- **底层事务状态**:状态包括TRANS_DEFAULT、TRANS_START、TRANS_INPROGRESS、TRANS_COMMIT、TRANS_ABORT、TRANS_DEFAULT,分别对应事务的初始、开启、运行、提交、回滚及结束状态。
#### 事务状态转换与实例
通过状态机实例展示事务执行流程,包括BEGIN、SELECT、END语句的执行过程,以及相应的状态转换。
- **BEGIN**:开始一个事务,状态从默认转为已开始,之后根据语句执行逻辑状态转换。
- **SELECT**:查询语句执行,状态保持为已开始或运行中,事务状态不发生变化。
- **END**:结束事务,状态从运行中或已开始转换为默认状态。
#### 事务ID分配与日志
事务ID(xid)以uint单调递增序列分配,用于标识每个事务,CLOG与CSNLOG分别记录事务的提交状态与序列号,采用SLRU机制管理日志,确保资源高效利用。
### 总结
事务机制在openGauss数据库中起着核心作用,通过详细的架构设计与状态管理,确保了数据操作的ACID属性,支持高并发环境下的高效、一致的数据处理。MVCC与事务ID的合理使用,进一步提升了数据库的性能与数据一致性。未来,将深入探讨事务并发控制的MVCC可见性判断机制与进程内的多线程管理机制,敬请期待。
å½å ä½ä»£ç å¹³å°åªå®¶å¼º
å¨å½å ä½ä»£ç å¹³å°å¸åºï¼è´è¿äºèå¯ä»¥è¯´æ¯ä¸ä¸ªé¢æç«äºåçä¼ä¸ãè´è¿äºèæ¯ä¸å½é¢å ç软件ç ååæå¡å ¬å¸ï¼è´åäºæä¾ä¼ä¸çº§åºç¨è½¯ä»¶çç åãå®æ½åæå¡ï¼å ¶ä½ä»£ç å¹³å°ä¹æ·±åç¨æ·çéçãååè¿è¥å¹³å°-å è´¹ä½éª
é¦å ï¼è´è¿äºèçä½ä»£ç å¹³å°å ·å¤ä¸°å¯çåè½åçµæ´»çæ©å±æ§ãå¹³å°å ç½®äºå¤§éç常ç¨ç»ä»¶å模åï¼å¯ä»¥å¿«éæ建ãè°è¯ååå¸åºç¨ç¨åºãåæ¶ï¼å¹³å°è¿æ¯æå®å¶åå¼åå模åå设计ï¼å¯ä»¥æ ¹æ®ä¼ä¸çå ·ä½éæ±è¿è¡äºæ¬¡å¼ååæ©å±ï¼æ»¡è¶³ä¸åè¡ä¸åä¼ä¸çéæ±ã
å ¶æ¬¡ï¼è´è¿äºèçä½ä»£ç å¹³å°å ·å¤ä¼ç§çæç¨æ§åæä½æ§ãå¹³å°éç¨å¯è§åçå¼åå·¥å ·åææ½å¼ççé¢è®¾è®¡ï¼ä½¿å¾å¼å人åæ éç¼åå¤æç代ç ï¼å³å¯å¿«éæ建åºç¨ç¨åºãåæ¶ï¼å¹³å°æä¾äºå好çæä½çé¢å详ç»çæä½æåï¼ä½¿å¾ä½¿ç¨è å¯ä»¥è½»æ¾ä¸æï¼æé«å¼åæçã
æåï¼è´è¿äºèçä½ä»£ç å¹³å°å ·å¤è¯å¥½çæ§è½åå¯é æ§ãå¹³å°éç¨å è¿çæ¶æåææ¯ï¼å ·å¤é«å¹¶åãé«å¯ç¨åé«å¯æ©å±æ§ï¼å¯ä»¥æ»¡è¶³ä¼ä¸ç大è§æ¨¡åºç¨éæ±ãåæ¶ï¼å¹³å°è¿å ·å¤å¼ºå¤§çå®å ¨æºå¶åæ°æ®é离è½åï¼å¯ä»¥ä¿æ¤ä¼ä¸æ°æ®çå®å ¨åéç§ã
è´è¿äºè为ä¼ä¸å»ç¹å°±ç®ï¼è®©å®¢æ·è½å¨ååå¹³å°ä¸ç¨éåä¼ä¸èªèº«çæ¹å¼è¿è¡è½¯ä»¶ãå©ç¨ééå®å¶çååå¹³å°åäºæå¡ï¼æ¯æåè¡ç¾ä¸å®ç°é«æè¿è¥å¹¶æç»è¿è¡ä¸å¡åæ°ï¼ä¸ºå®¢æ·æä¾æ¾å¿ãçå¿ãèå¿çæ°æºå·¥ä½ä½éªã
分布式锁技术探究 - Redisson & curator 源码解读
在高并发场景中,为解决资源竞争和共享问题,引入了分布式锁,衍生出可重入锁、读写锁等。随着服务架构的分布式化,这些并发问题扩展到了分布式场景,业务中需要分布式锁和分布式AQS来确保资源管理。
分布式锁的实现方式多样,如基于Redis的Redisson和Zookeeper的Curator。Redisson利用redLock算法避免主从复制导致的重复加锁,但存在单点故障问题。Curator则依赖zk的临时顺序节点实现锁,提供了一种更健壮的解决方案。
要选择分布式锁,需关注其基本特性,如高可用性、线程安全、可重入性、锁的公平性等。Redisson的锁模型通过lua脚本保证原子性和公平性,而Curator的zk实现则利用watcher机制实现公平锁。
Redisson提供更丰富的功能,如可重入锁、读写锁,以及通过lua脚本实现的高级特性。而zk的zk锁模型更为简单,公平性较好,适用于对强一致性要求较低的场景。
总结来说,选择哪种分布式锁取决于业务需求和性能要求,Redisson适合竞争激烈但对一致性要求不高的场景,而zk在强一致性方面更有优势。
delphi源码,三层源码中间件
这套Delphi源码设计用于企业级应用系统开发,如ERP、MES、HRMS和库存管理系统,相较于常规中间件,它具有更丰富的功能和更直观的开发体验。对于需要处理高并发、跨平台、高效实时系统的开发者,可能需要自行优化。该框架不依赖第三方控件,以简单明了的方式封装常用功能,注重实用而非复杂技术。
开发环境方面,原基于Delphi ,已升级至Delphi ,采用DataSnap架构。服务器使用SQLite存储配置参数,客户端使用MS SQL数据库,并结合DevExpress VCL和FastReport控件。
服务端部分,专注于功能实现而非图形展示,而客户端则是一个针对制造业的MES系统,核心功能包括计件工资计算、产量分析和生产进度跟踪。此外,还有一个Java版APP和H5手机端应用,用于数据上报和查询,但并未包含在公开分享的内容中,如有需要,可单独联系获取。
å½å ä½ä»£ç å¹³å°åªå®¶å¼ºï¼
è¯ä¸å¤è¯´ï¼ç´æ¥ç»å¤§å®¶æ¨èå 个å½å æ¯è¾ä¸»æµçä½ä»£ç å¼åå¹³å°ï¼1ãç»ä¿¡Informatï¼æ¯æ·±å³åºç³åä½æ¨åºçé¢åä¸å¡äººåçä½/é¶ä»£ç å¼åå¹³å°ï¼å ·æé«åº¦çµæ´»çâæ°æ®+æé+æµç¨âå¨æä¿¡æ¯ç®¡ç模åï¼ç¨æ·ä¸åéè¦ä»¥æ¥ä»£ç å¼åï¼å¯ä»¥éè¿èªä¸»é ç½®çæ¹å¼ï¼å¿«éæ建ä¼ä¸è¿è¥æéçå类管çç³»ç»ãèä¸å®ä¸ä¼ä¸å¾®ä¿¡ãééç´§å¯éæï¼è½å¤å¤§å¹ è约ç åææ¬åæ¶é´ï¼å¸®å©ä¼ä¸å®ç°å ¨æ¹ä½çæ°åå转åãå®è¿æä¾äº+ç°æçåºç¨åè¡ä¸æ¨¡æ¿ï¼ä¼ä¸ä¸éè¦ä»é¶å¼å§ï¼ç´æ¥åºäºåºç¨æ模æ¿æ¥ä¿®æ¹ææå±åè½ï¼å¯ä»¥æ´å¿«éé«æå°æ建åºè´´è¿éæ±çåºç¨ã
第äºä¸ªï¼ééå®æï¼é¿éèªå·±å¼åçä½ä»£ç å¹³å°ï¼è·ééä¹ææ¯è¾æ·±åº¦çç»å®ï¼å ¶å®åè½é½æ¯å·®ä¸å¤çï¼éè¿æææ½çæ¹å¼è®¾è®¡è¡¨å设计æµç¨ï¼è®¾è®¡ä»ªè¡¨çä¹åï¼ä½ å¯ä»¥ä¸é®æå®åå¸å°çµè端åææºç«¯ï¼è®©ä½ å ¬å¸å ¶ä»åäºæ¥ä½¿ç¨ã
第ä¸ä¸ªæ¯å¥¥å²ï¼è¿ä¸ªä¹æ¯ééåè¡çãå®çç¹ç¹æ¯é¢åä¸åçåºæ¯åä¸åç人群åäºä¸äºç»åãæ¯å¦è¯´ï¼æé¢åä¸ä¸å¼åè çãé¢åä¸å¡äººç¾¤çãé¢åæ°åå管çåçï¼ä½ å¯ä»¥æ ¹æ®ä½ ä»¬å ¬å¸ä¸åçå¼åæ°´å¹³å»éæ©æä¸ä¸ªã
第å个æ¯ææ³äºãæä¹æ以ä»ç»è¿ä¸ç¹ï¼æ¯åç°ä»ä»¬æ OA å CRM åäºæéï¼ç¸å½äºæ¯ä¸æ³¨å¨æä¸ä¸ªç¹ä¸ãå¦æä½ å¯¹è¿æ¹é¢éæ±æ¯è¾å¼ºçè¯ï¼å¯ä»¥è¯ä¸è¯ã
第äºä¸ªå¢å°±æ¯ä¼ä¼´äºï¼åå§äººæ¯æ´å¿åº·ï¼è¿å»çååä¸åå°ï¼å½æ¶åä¸å°±åäºDiscuzï¼å½å ç论å软件ï¼å ¶å®ä¸ç´ä¹æ¯ To B å¾ï¼ä¹æ¯å½å ææ©ä¸æ¹åé¶ä»£ç å¼åå¹³å°çã
ä»ä»¬å ¶å®è·ä¼ä¸å¾®ä¿¡çæéæ¯è¾å¤ï¼ä½ å¨ä¼ä¸å¾®ä¿¡éè¾¹å线ä¸çéå®ï¼ä¸æ´å¥çCRMæµç¨ä»ä»¬åçæ¯æ¯è¾å®åçã
第å 个就æ¯æéäºï¼è¿ä¹æ¯ä¸ä¸ªé常èççåä¸å ¬å¸äºï¼ä»ææ©æéå»åä¼ä¸æå¡ï¼ç¶åç°å¨æéäºåçä½ä»£ç ãä»ä»¬å®¶çæä¸ä¸ªç¹ç¹å°±æ¯è½å¤æä¾ç§æåçé¨ç½²ã
å¦æä½ å¯¹æ°æ®å®å ¨åæ¹é¢æè¦æ±çè¯ï¼ä½ å°±å¯ä»¥è¯è¯ï¼ä»ä»¬æè§ä¼æ´éåä¸å¤§åçä¼ä¸ã
第ä¸ä¸ªå°±æ¯ç®éäºï¼æåç°ä»ä»¬çä»ç»åå¾ç¹å«å¥½ï¼ä½ ç¨å®å»åå¼åï¼åºæ¬ä¸å°±æ¯ä¸æ¥ï¼ç¬¬ä¸æ¥æ¯è®¾è®¡è¡¨åï¼ç¬¬äºæ¥è®¾è®¡æµç¨ï¼ç¬¬ä¸ä¸ªå°±æ¯ä»ªè¡¨çãç®åçåºç¨æ建ç¨å®è¿è¡ã
以ä¸å 容ï¼å¸æ大家ææ帮å©ï¼